Related
Hi i have 16GB sdcard class 2 what is the size of SWAP and EXT2 for A2SD ?
thanks
I chose 2GB Swap and 100MB Ext2 Runs like a (HTC) Dream!
Seriously, pick whatever suits you best or just search for what people recommend. There is no reason to start a new thread.
You won't need a swap and 1GB Ext2 would be more than sufficient.
you really should search before posting.
You should really read the rules before posting.
The rules would have told you that you should have searched.
-------------------------------------------------------------->>>
There is some discussion on this but imho...
1) I wouldn't use a class 2 card; full stop. Very slow card.
2) Don't use a swap -->
-->Android manages memory very well.
-->The desire has 576MB of RAM
-->Your SD card is only good for around 10,000 write cycles.
-->Writing to SD is fairly battery hungry. (see point 1 also)
3) EXT2/3/4 partition size is really a personal choice. Not much point in anything bigger than 2GB as the /data/data will remain on the phone and imho, in most cases, that would be getting close to full by the time you have 2 gigs of apps on your SD card anyway.
A two... gig swap? Jesus Christ.
0MB swap, 512MB EXT3 is probably more than you'll ever need.
To be fair, if you want things to be fast, leave it as ext2, there is no need for the journaling that ext3 has to offer, so its wasted read/write cycles for it tbh...
interesting. But why then are ext3 and ext4 even available ?!
Between ext2, ext3 and ext4, what is the best ?
2 = known entity, stable, simple. Used to be a 2GB limit but not sure now. This was in the early days of g1 rooting and I think it was a limitation of early Android releases.
3 = journaling support (unnecessary imo) no size limit. (in practical terms in this use)
4 = new, not well tested, possibly unstable, journaling, no size limit.
I reckon ext2 but I'm sure having posted this someone else will suggest a reason that 3 or 4 is better. Do some messing about. See if you can come up with any useful findings! I'm all ears!
have read someware that ext3 is more stable so the choise is with ext2 fast or ext3 stability imho.
i don't think you will notice the difference in speed, i prefere ext3
Sent from my HTC Desire using the XDA mobile application powered by Tapatalk
kiokoman said:
have read someware that ext3 is more stable so the choise is with ext2 fast or ext3 stability imho.
i don't think you will notice the difference in speed, i prefere ext3
Sent from my HTC Desire using the XDA mobile application powered by Tapatalk
Click to expand...
Click to collapse
I think journaling is a consideration too. I don't fully understand journaling but above this there is a post pointing out the extra write cycles. Is this going to effect battery life/sd card life?
1) i don't think about battery maybe a couple of second per day?
2) this is why most people suggest a Class 6 cards that support wear leveling
http://en.wikipedia.org/wiki/Wear_levelling
more info about file system and why ext3
http://en.wikipedia.org/wiki/Ext3
citation: "Its main advantage over ext2 is journaling which improves reliability and eliminates the need to check the file system after an unclean shutdown."
and for what i know when you turn off the phone the ext3 partition is not unmounted
Great idea Chainfire.
When a user first decided to use a modified/custom/different firmware on their Samsung Galaxy S, they usually go through these steps:
1. Flash with Odin/Kies
2. Flash update.zip for root
3. Flash other update.zip (GPS fix, battery mod, etc) as necessary
4. Do a lag fix.
It took me a few hours and reading through countless posts to see the pro's and con's for each lag fix.
I will try to go through them as succintly as possible, and if anyone needs more explanation you can either click the link or do a search.
Feel free to correct me, this is how I see the lagfix as when I applied and tested it
Before starting, here is the internal structure of non volatile memory (where data persist after reboots) in Samsung Galaxy S:
- 128MB of very fast NAND (some people incorrectly called this ROM)
- 16/8GB of internal SD with 2GB set aside for application installs (this is why you see your internal SD as either 13+ or 5+ remaining, the 2GB shows up as Internal Phone storage)
- your micro SD card (external SD)
The lag is due to the inefficiency of the file system used in the 2GB (/data) partition for applications, stalling a lot of the read/write operation. You can search this for further reading if you want to.
Lag fixes
- MoDaCo's lagfix: Better than stock on old F/Ws but about the same as JM1/2/5 and JP1/2/3
This lagfix uses the 128MB very fast NAND to store your applications instead.
Pro: very very fast applications opening/switching performance
Cons: You are limited to 128MB of apps including built in apps .
- Mimocan's lagfix: Significant improvements in performance which can also be benchmarked. Requires an external SDcard formatted partly in fat and partly ext3 or ext4.
This moves the /data files into the ext3/ext4 partition on an external microSD card
Pros: very fast, lots of storage space for apps
Cons: You will be unable to unmount your external SD card when the phone is on, and you need an external SD card for this to work
- OneClick Lagfix by RyanZA: Based on mimocan but using the internal SD card. Results are better than with basic mimocan and it is a lot easier to install.
This creates a file inside the 2GB partition that is mounted as /data.
Pros: very fast, lots of storage space for apps, easy to install and undo, available in the market.
Cons: if you install too many apps you won't be able to roll back the lag fix unless you delete some apps. Superseded by RyanZA lag fix 2.3 beta
Erroneous free space on Internal Phone storage (/data)
There are still stalls when installing apps, and when accessing android applications database
- CFLagFix by Chainfire: Based on mimocan, approximately the same as RyanZA's fix.
pretty much the same as OneClick Lagfix.
look above for Pros
Cons: There are still stalls when installing apps, and when accessing android applications database
-Voodoo lag fix by supercurio: a new class of total lag fix
Instead of creating a file inside the rfs partition and mounting it as /data/data, the voodoo lag fix updates the kernel so that the the 2GB partition is using ext4 instead or rfs. This gives the best possible lag fix.
Pros: fast, smooth, across everything you do. The way galaxy s should have been in the first place. The best and most consistent lag fix with no remaining lag left that is caused by rfs.
Support with other kernel mods are starting to show: backlight mod, OC/UV kernel
Cons: Incompatible with clockworkmod recovery
I am now using voodoo lagfix beta 4 only
http://project-voodoo.org/
Love the Vodoo color would like to try this as well...they are getting OUTRAGIOUS numbers in quadrant!
1deviant said:
Great idea Chainfire.
When a user first decided to use a modified/custom/different firmware on their Samsung Galaxy S, they usually go through these steps:
1. Flash with Odin/Kies
2. Flash update.zip for root
3. Flash other update.zip (GPS fix, battery mod, etc) as necessary
4. Do a lag fix.
It took me a few hours and reading through countless posts to see the pro's and con's for each lag fix.
I will try to go through them as succintly as possible, and if anyone needs more explanation you can either click the link or do a search.
Feel free to correct me, this is how I see the lagfix as when I applied and tested it
Before starting, here is the internal structure of non volatile memory (where data persist after reboots) in Samsung Galaxy S:
- 128MB of very fast NAND (some people incorrectly called this ROM)
- 16/8GB of internal SD with 2GB set aside for application installs (this is why you see your internal SD as either 13+ or 5+ remaining, the 2GB shows up as Internal Phone storage)
- your micro SD card (external SD)
The lag is due to the inefficiency of the file system used in the 2GB (/data) partition for applications, stalling a lot of the read/write operation. You can search this for further reading if you want to.
Lag fixes
- MoDaCo's lagfix: Better than stock on old F/Ws but about the same as JM1/2/5 and JP1/2/3
This lagfix uses the 128MB very fast NAND to store your applications instead.
Pro: very very fast applications opening/switching performance
Cons: You are limited to 128MB of apps including built in apps .
- Mimocan's lagfix: Significant improvements in performance which can also be benchmarked. Requires an external SDcard formatted partly in fat and partly ext3 or ext4.
This moves the /data files into the ext3/ext4 partition on an external microSD card
Pros: very fast, lots of storage space for apps
Cons: You will be unable to unmount your external SD card when the phone is on, and you need an external SD card for this to work
- OneClick Lagfix by RyanZA: Based on mimocan but using the internal SD card. Results are better than with basic mimocan and it is a lot easier to install.
This creates a file inside the 2GB partition that is mounted as /data.
Pros: very fast, lots of storage space for apps, easy to install and undo, available in the market.
Cons: if you install too many apps you won't be able to roll back the lag fix unless you delete some apps. Superseded by RyanZA lag fix 2.3 beta
Erroneous free space on Internal Phone storage (/data)
There are still stalls when installing apps, and when accessing android applications database
- CFLagFix by Chainfire: Based on mimocan, approximately the same as RyanZA's fix.
pretty much the same as OneClick Lagfix.
look above for Pros
Cons: There are still stalls when installing apps, and when accessing android applications database
-Voodoo lag fix by supercurio: a new class of total lag fix
Instead of creating a file inside the rfs partition and mounting it as /data/data, the voodoo lag fix updates the kernel so that the the 2GB partition is using ext4 instead or rfs. This gives the best possible lag fix.
Pros: fast, smooth, across everything you do. The way galaxy s should have been in the first place. The best and most consistent lag fix with no remaining lag left that is caused by rfs.
Support with other kernel mods are starting to show: backlight mod, OC/UV kernel
Cons: Incompatible with clockworkmod recovery
I am now using voodoo lagfix beta 4 only
http://project-voodoo.org/
Love the Vodoo color would like to try this as well...they are getting OUTRAGIOUS numbers in quadrant!
Click to expand...
Click to collapse
I believe we have diffrent ext partitions than on the other galaxy s variants.
Sent from my SPH-D700 using XDA App
the epic doesn't need a lag fix. the quadrant numbers are due to a flaw in quadrant. the lag fix isn't really providing that much better performance (except fixing the lag for phones that need it), quadrant just blows the score out of proportion. Cyanogen was able to tailor an exploit to show this happens on any phone: http://briefmobile.com/cyanogen-demonstrates-quadrants-flaws
as for voodoo color, I don't believe there is a general port yet, but it is built-in to the MixUp kernel.
dwyw42 said:
the epic doesn't need a lag fix. the quadrant numbers are due to a flaw in quadrant. the lag fix isn't really providing that much better performance (except fixing the lag for phones that need it), quadrant just blows the score out of proportion. Cyanogen was able to tailor an exploit to show this happens on any phone: http://briefmobile.com/cyanogen-demonstrates-quadrants-flaws
as for voodoo color, I don't believe there is a general port yet, but it is built-in to the MixUp kernel.
Click to expand...
Click to collapse
I have the mixup kernel w/vodoo and love it! I just saw this NFO and wanted a more educated explaination...now I have it!
Forever looking to run faster, just one of my many flaws..never satisfied.
Do love my Epic!!!
Its included in the boss rom and GenuisDogs kernels
Wait a minute? Are you saying that its possible for the voodoo lag fix to be ported to the Epic 4g and thus making this fast phone faster? Am I reading correctly? (I saw on his page that they are planning to work on te Epic as well)
We do not need the lag fix. The lag fix will not make our phone any faster.
voodoo cons: needs more battery than oclf or chainfire's fix
my experience is, that voodoo is less smooth (less means a bit less but its great too - not laggy)
Eazail70x7 said:
Wait a minute? Are you saying that its possible for the voodoo lag fix to be ported to the Epic 4g and thus making this fast phone faster? Am I reading correctly? (I saw on his page that they are planning to work on te Epic as well)
Click to expand...
Click to collapse
I talked to Supercurio about me porting it before, but we came to the conclusion that it's unnecessary. We don't use the same NAND chips as the other phones, so we don't have to deal with all the lag **** except what's introduced with RFS. And changing from RFS breaks clockworkmod, so I am avoiding it.
All this is nice,but why is nobody talkin about a fix to use whole 512mb of ram instead 324mb?I had MTS3GS with 600mhz cpu and 512 ram and I hate to admit but it was faster than my Epic even with Sence.If someone could come up with a fix to use whole 512mb instead of 324mb then this phone would fly,this is the only thing that hinders this phone.Rest of the ram is used for cache(ramdisk).
What needs to be done is whole 512mb used for ram and fast NAND used for cache.324mb ram is not sufficient to run android smoothly.
lviv73 said:
All this is nice,but why is nobody talkin about a fix to use whole 512mb of ram instead 324mb?I had MTS3GS with 600mhz cpu and 512 ram and I hate to admit but it was faster than my Epic even with Sence.If someone could come up with a fix to use whole 512mb instead of 324mb then this phone would fly,this is the only thing that hinders this phone.Rest of the ram is used for cache(ramdisk).
What needs to be done is whole 512mb used for ram and fast NAND used for cache.324mb ram is not sufficient to run android smoothly.
Click to expand...
Click to collapse
I'm trying to decide if you are trolling this thread or if you recently suffered head trauma. Those are the two most likely things that I can imagine would cause someone to say the MTS3GS is anywhere near as fast as the epic.
richse said:
I'm trying to decide if you are trolling this thread or if you recently suffered head trauma. Those are the two most likely things that I can imagine would cause someone to say the MTS3GS is anywhere near as fast as the epic.
Click to expand...
Click to collapse
B,talk to ur moms like that fagit,i had mytouch slide and it was just as fast if not faster with haf of cpu power.
lviv73 said:
B,talk to ur moms like that fagit,i had mytouch slide and it was just as fast if not faster with haf of cpu power.
Click to expand...
Click to collapse
Could someone translate this from "stupid" into english so I can read it and possibly respond?
Lol I'm having a difficult time myself.....is it really faster than the epic? Unlike some people, I don't post nonsense that I know nothing about...I would rather ask first and try and get a correct answer
Sent from my SPH-D700 using XDA App
specialk0324 said:
Lol I'm having a difficult time myself.....is it really faster than the epic? Unlike some people, I don't post nonsense that I know nothing about...I would rather ask first and try and get a correct answer
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Yeah man,mytouch slide was the fastest phone I ever owned(with 2.1),i think that having 512mb ram is better than having 1ghz cpu.If Epic used 512MB it would most likely be even faster.
Which I tried explaining to the last dude before that ***** came at me wrong without a reason,but its the intenet what can you do,lol.
Just to squash any kind of confusion in this thread...
In no way is the Mytouch Slide faster than the Epic 4G.
/thread
infamousjax said:
Just to squash any kind of confusion in this thread...
In no way is the Mytouch Slide faster than the Epic 4G.
/thread
Click to expand...
Click to collapse
Go to tmobile and use one with stock 2.1 its just as fast as epic.I dont know what they did to that underpowered phone but its fast.It might not be as fast watching videos,loadind games,etc.But android system itself is fast and more snappy then Epic,i compared the two,gotta be extra ram.
Don't take this the wrong way....but if it didn't load games or play movies as fast, doesn't that at least in part make the epic faster?
Sent from my SPH-D700 using XDA App
infamousjax said:
Just to squash any kind of confusion in this thread...
In no way is the Mytouch Slide faster than the Epic 4G.
/thread
Click to expand...
Click to collapse
+1 agreed, there is no way.
Sent from my SPH-D700 using XDA App
Are there any other existing kernels for sgs4g besides the ones on the first page?
Reason I ask is because I'm trying to use a swap partition, but it seems these kernels are not swap enabled.
Why has nobody bothered to compile any custom kernels for the sgs4g? I am trying myself, but no luck so far.
Any ideas?
Thanks,
S
sconsylman said:
Are there any other existing kernels for sgs4g besides the ones on the first page?
Reason I ask is because I'm trying to use a swap partition, but it seems these kernels are not swap enabled.
Why has nobody bothered to compile any custom kernels for the sgs4g? I am trying myself, but no luck so far.
Any ideas?
Thanks,
S
Click to expand...
Click to collapse
I'm not sure I can answer the whole question as to why we don't use swap, but I can say that we just got the GB kernel source, and people are still working on it and haven't posted anything.... yet. Patients...
But, I noticed that the Bali 3.3 kernel (KD1) also did not have swap. Maybe drhonk and Krylon360 tried it and swap didn't help or improve performance.
The rest of the kernels you'll find are either stock leaks, or modified stock leaks. Samsung doesn't like swap I guess. Or swapping on SD/MMC sucks hard.
I know in newer kernels (3.0 and greater), there is a new driver for mtd-swap, but it is still very new and I doubt anyone will use it in production for quite some time.
Using swap on Android is not such a great idea, it goes a little bit against native Android memory management. Then benefit can be that more programs will stay in memory and won't need to reload, but the phone will become a lot slower, even with small partitions like 32MB. With 128MB or higher it will become almost unusable. Ask me how I know
I think the need for swap was gone once phones started coming with 512mb+ ram. I used swap all the time (also required for GB) on my MT3G, since it only had like 192mb ram. It never made the phone work faster at all, in fact it usually slowed down over time running, it really just made it so stuff didn't force close due to running out of memory. This shouldn't be needed on this or any new phone.
So Bali 3.3 is a GingerBread build? Didn't know that. Kinda figures I guess. Thought I had already tried it though and couldn't bootload. I'll give it another whack. His stuff is awesome of course. I'm not demanding it, mind you, just trying to see why it would not be included. Kind of like not having a /proc/config.gz file in some Android builds, don't really know the reason why they're not included (results in not able to mount ubuntu builds, anybody have these let me know .
This appears to be the only source of kernels for our phones, no swap support enabled though. http://forum.xda-developers.com/showthread.php?t=1194032
(Thanks dr.honk!)
As for the swap partition not making sense, I have a hard time understanding why it wouldn't just provide a static and beneficial extended memory source. I am familiar with the memory management features of Android, and actually don't use any additional task killers as I've found them to be conflicting often.
But Android is built off the Linux system/kernel, so why does dedicated swap work with a large OS but not the smaller but similar Android OS/kernel?
Thanks!
sconsylman said:
As for the swap partition not making sense, I have a hard time understanding why it wouldn't just provide a static and beneficial extended memory source. I am familiar with the memory management features of Android, and actually don't use any additional task killers as I've found them to be conflicting often.
But Android is built off the Linux system/kernel, so why does dedicated swap work with a large OS but not the smaller but similar Android OS/kernel?
Click to expand...
Click to collapse
In short, the phone will become annoyingly slow.
Swap works on kernel level. Android will see this as additional virtual memory, so it will keep more programs alive and won't unload them. For example a browser will hog a lot of memory causing other programs' memory pages to be swapped. Kernel doesn't differentiate between programs, so, for example, the launcher memory pages will be swapped. Or even the active program you are currently working with can have part of its memory in the swap. Next time you try to do something (like scrolling), the memory pages will have to be brought back. Flash memory is not particularly fast (in fact for swap it is very slow), so you can we waiting for some noticeable time for many actions to complete. You'll have a lot of jerky movements, delays, temporary freezes, forget any smoothness. It is just annoying, trust me, I've tried
Ah, ok so the swapping is noticeably slower than the ram on the phone (512mb). I would not figure that it would be too much of a factor, especially on class 6+ sd cards. So there is absolutely no way of coding the system apps to be ram based, and everything else to be swappable? I'm surprised that this has not been done, but I assume that the reason is the expanding active ram capacities on new phones.
So were you experimenting on the sgs4g, or was it another model? And if so, what were you using? Froyo swap enabled kernel?
The HTC Thunderbolt has some similar specs.
http://forum.xda-developers.com/showthread.php?t=1106420
More ram 768mb vs 512mb, more internal storage 4g vs 1000mb, but uses a 1g single core scorpion processor instead of our 1g single core hummingbird. Some are having good luck with this device and swapping (taking all "facts" with a grain of salt). There is more like this too, with a number of market apps to support swapping: Swapper2, Swap for Root, Diaper swappers forum (oops, that one doesn't work for some reason).
sconsylman said:
So Bali 3.3 is a GingerBread build? Didn't know that. Kinda figures I guess.
Click to expand...
Click to collapse
No, Bali 3.3 is Froyo.
I did try it on this phone few months ago when I was still on Froyo with Bali kernel. Don't try to load in on GB, wait until DrHonk makes a new one, he actually may soon.
I personally can't imagine how anybody could use swap on Android and like it, but everybody's mileage varies. The benefit of using swap wouldn't be speed but rather less program reloads. For example you browse the web when a call comes. You answer the call, maybe go to address book, or take some notes, or send some pictures, etc. Everything will be a little slow and jerky, but with swap enabled you have better chance that when returning to the browser it will still be on the same page without reloading from the server.
Just checking again to see if anyone knows of any KJ6 kernels with swap enabled, as I'm currently getting memory warnings from running Backtrack 5 non-gnome. It works pretty well otherwise (besides the lack of space, thanks obsolete fat32).
??
sconsylman said:
Just checking again to see if anyone knows of any KJ6 kernels with swap enabled, as I'm currently getting memory warnings from running Backtrack 5 non-gnome. It works pretty well otherwise (besides the lack of space, thanks obsolete fat32).
??
Click to expand...
Click to collapse
No swap. what version of the kernel are you running?
bhundven said:
No swap. what version of the kernel are you running?
Click to expand...
Click to collapse
Sent from my SGH-T959V using xda premium
2.6.35.7 KJ6-CL694138
It has [email protected]#9 signature on it. I know we had spoken briefly about swap. What linux are you running?
I know that the Debdroid program is successfully running swap with good results, but it won't mount right with the specific scripts (our phones working mount scripts are different, I linked them in my linux post). I can take some coding from that programs scripts but of course it won't work without the kernel having swap built in.
Sent from my SGH-T959V using xda premium
http://forum.xda-developers.com/showthread.php?t=2104326
Hi,
Saw this on reddit this morning, as no one's posted it yet I'd just like to offer it up as another potential lag-fixer.
The source of the problem is that internal storage is not properly TRIMmed when needed. You can find lots of information on XDA - http://forum.xda-developers.com/show....php?t=1971852 and http://forum.xda-developers.com/show....php?t=1929021 for example. It is also well-known fact that running fstrim Linux tool from time to time fixes the issue until internal memory runs out of free blocks. Other solutions like mounting with -discard or disabling fsync may be dangerous.
LagFix is a user-friendly implementation of fstrim utility. It allows you to select which partitions to trim (you should leave defaults unless you know what you are doing) and run the process easily.
Please note that fstrim output depends on kernel and device. It works fine unless you see errors. You might see big amounts of bytes, zero amount or repeating amount. All are fine! Read fstrim manual to understand why all these outputs are valid.
It is also advised to reboot your device after the TRIM process so that kernel could reinitialize block data.
App is free and is available in Play Market. Current version is 1.0.
P.S. If your ROM mounts /data with -discard then this app is NOT needed! Mounting with -discard causes brickbug on some devices, so I DO NOT advise using -discard.
Click to expand...
Click to collapse
Link on Play: https://play.google.com/store/apps/details?id=com.grilledmonkey.lagfix
I applied it on my rooted, locked tf700 and, well, nothing bad happened. I am on the .25 update, which I feel made overall app-opening a little smoother, so I can't tell if this makes any noticeable difference, but it certainly doesn't seem slower after applying it. The dev says that if you run androbench after applying the fix i/o read should be higher, if anyone could run a few benchmarks of before/after it would be appreciated! I've never really placed much faith in benchmarks so didn't bother doing it myself.
Hope this benefits someone!
Sent from my ASUS Transformer Pad TF700T using Tapatalk HD
I downloaded and installed it. Ran it, rebooted. It did trim, but the jury is still out on whether this actually helps or not. It's too freshly booted to really judge the effects properly, so I'll have it settle in and report back.
It didn't break my 700 -- that's a good thing to start with.
MartyHulskemper said:
I downloaded and installed it. Ran it, rebooted. It did trim, but the jury is still out on whether this actually helps or not. It's too freshly booted to really judge the effects properly, so I'll have it settle in and report back.
It didn't break my 700 -- that's a good thing to start with.
Click to expand...
Click to collapse
Yeah, I was reluctant to be the first one to try it on an infinity... But it worked out for the better, I think. Now I don't know if the .25 jb update or this is to thank for the better performance. It should hope up till the 4.2 update at least! Quite pleased with the .25 update
Sent from my Galaxy Nexus using Tapatalk 2
Just tried it. Could be my imagination, but my tablet seems snappier.
I am not convinced that it will have any effect: TF700's Hynix eNAND flash is eMMC 4.41 compliant, which does not have DISCARD command, the equivalent of SATA's TRIM command. The DISCARD command is supported in eMMC 4.51 compliant flash but I don't know if the Kingston flash in Nexus 7 is eMMC 4.51 compliant. Even if it does TRIM the TF700, probably it will have little effect if you have alot of free space left as it does not affect the garbage collection significantly. One would hope that TRIM should already be done dynamically within the file management software as it would reduce write amplification factor, hence improve write speed performance?
Kraka said:
I am not convinced that it will have any effect: TF700's Hynix eNAND flash is eMMC 4.41 compliant, which does not have DISCARD command, the equivalent of SATA's TRIM command.
Click to expand...
Click to collapse
According to the spec, eMMC 4.41 supports TRIM - what's the difference between TRIM and DISCARD?
I read that eMMC 4.41 also supports "background operation" and "high priority interrupt" - these sound much more interesting related to lag than TRIM. Do you have any idea if these features are already used in the TF700's Linux kernel (or even at all in any kernel)?
faq in op link said:
Which devices are affected?
It is known by now, that Nexus S, Galaxy Nexus, Nexus 7, Nexus 4, Nexus 10 and HTC One X need regular trimming. It is also believed that all pre-ICS devices used different memory and they do NOT need it nor support it. Pre-ICS support will be dropped in version 1.2. Other 4.0+ devices? Well, test it! And report if it really helps - your device will be added to the list.
How to properly test it?
Use AndroBench app before using LagFix and after. You only need micro test. Look for Sequential Write values. Reading from memory is NOT affected, because reading does not involve writting and only writting triggers search party for free memory blocks.
Click to expand...
Click to collapse
For anyone looking for early confirmation of impact.
I think I'll give this a try. I have some hefty typing lag. I thought one of the first updates had gotten rid of it, but it came back, it was just temporarily relieved by the fresh reboot then. If it does help, it'll probably be a month before I confirm anything, just to avoid giving/having false hope . Thanks for posting op hope it works.
Edit, sorry, just noticed OP already mentioned androbench.
Edit 2: Saw no change in my androbench write speed. Sequential write was something over 5MB/s, random write was .15MB/s both before and after running it, and again after rebooting. lagfix claimed to have trimmed successfully. If anything, it felt more laggy for a while after running it. I'm an OS update or two behind FWIW, just installed Jelly Bean a month or so ago. I like to let everyone else test the updates before I install them. I'll probably run another bench this evening. :shrug:
fsTRIM = AWESOME fix - on CROMI, OCed kernel, fsync disabled
I just download the fsTRIM app and it worked with CROMI, OCed kernel, and fsync disabled. Will seem laggy right after runnng it, just reboot as soon as you do and things will be deffinitely running smoother and slightly faster now. Noticing less keyboard latency even as I type this out. I suggest trying it out.
UPDATE - Seriously try this **** out. Keyboard typing is radically smoother in browser, evernote, and google drive. Less latency between multi touch gestures ive set up in GMD Gesture Control as well. App opening is still instantaneous. Loading big web pages is definitely quicker. Will time boot and other things and update again soon.
Update - Opening large files and youtube is faster. large pdfs load faster. everything is really....snappy, and.....smooth.....best of both worlds. things were already pretty snappy and smooth with CROMI, didnt think they could get better but it has. I time everything as well to compare. I could barely time it after this fix as everything is basically instantaneous. Havent tried writing/moving large files on internal storage yet, will test soon, this is distracting me from my homework too much lol.
It works for me I can now download files and move them without having my tablet unusable until it's done.
Sent from my ASUS Transformer Pad TF700T using Tapatalk HD
Just installed this.
Will give it a go...
lucius.zen said:
...
Click to expand...
Click to collapse
You posted the same content in two other thread sof you own making, and in this one. One helluva way to get to 2000 posts without interjecting anything actually useful. Neitehr is this post, I will mention myself, but please keep a lower profile next time.
So far I haven't noticed any difference at all. I'll give it the rest of the day and if I don't feel there is any change I'll just uninstall.
Hello i am a bit confused if starting to use F2FS system or not.
Can an User give me hes opinion?
and does it work with MultiROM?
F2FS brings better write speeds, but worse read speeds. Also, F2FS is still really new and could bring data loss. And finally, if you decide that you've had enough of f2fs, you have to wipe and start over by converting the filesystem back into ext4
I personally would stick with ext4. The negligible speed difference is not worth the problems that come with f2fs