Android 4.3 Update Brings TRIM to All Nexus Devices
The Android framework will send out a “start idle maintenance window” event that the MountService listens for, and then invokes vold to fstrim filesystems when a few conditions have been met – the device hasn’t been touched for over an hour, no idle maintenance window event has been sent in 24 hours, and the device is either off-charger with 80% battery or on-charger with 30% battery. The goal is to have fstrim run roughly once every 24 hours if you’re in the habit of plugging the device in to charge every night.
Click to expand...
Click to collapse
Finally Google, you hear us out! Thanks.
Great review from anandtech as always: #fstrim #trim #vold #android #nexus
http://www.anandtech.com/show/7185/android-43-update-brings-trim-to-all-nexus-devices
I really wish Google will also implement the Moto X's Flash Friendly File System aka f2fs on next version of Android to improve random write IOPS and overall system responsiveness.
http://www.anandtech.com/show/7235/moto-x-review/9
-------------
Dear All,
I've been curious after reading Anandtech articles regarding Asus Nexus 7 storage performance and how it compared to other Asus Tablet and Galaxy Nexus. Using Androbench app from Google Play as their tool, I managed to get the result of my Galaxy Nexus after it being used to watch tv series this last three week, and to my surprise, the performance was slowed down perhaps because all the capacity has been used and overwritten and thus having this write amplification effect on flash memory and ssd.
I don't know how to TRIM a eMMC storage on Galaxy Nexus, neither have the knowledge of app or tweak to TRIM, thus I reset to factory image since it formated six partition and restore each to a clean slate with the bootloader, radio, system, userdata, boot, and recovery images. So here's the result I found as per attached. The results were quite shocking though not so significant but it seemed the flashing of the images did restore the storage performance back to normal.
Now I wonder if Linux kernel on Android Jelly Bean supports or will support automatic trimming the eMMC in the near future so it will restore the eMMC (storage) write performance when idling, or is there a tool or adb command to trigger the TRIM command so we don't have to do the backup and restore when resetting to Google factory image?
Resources:
Anandtech: Exploring the Relationship Between Spare Area and Performance Consistency in Modern SSDs
Anandtech: Asus Nexus 7 Storage Performance
Anandtech: SSD Anthology
Anandtech: Performance Over Time and TRIM
Wikipedia: TRIM
Debian Linux SSD Optimization
Impact of ext4′s discard option on my SSD
Android on eMMC: Optimizing for Performance
LINARO: Intro to eMMC - Effectiveness of TRIM
I found bug reported on Android Open Source Project with Issues ID 37258. The screenshots of their Androbench app results were scary, reach below 1Mbps for sequential write (recall the USB1.1 performance?).
Please vote for this issues if you're having similar slow down experience after using your sdcard's capacity to the max. There are already more than 200 people vote for this issue. The more people vote the more chance AOSP developer would hear us out. To vote, click the star icon below add comment section on bottom of this following Android Open Source Issues page:
Nexus 7 Poor Write Speeds After Using Almost All Storage Capacity
Galaxy Nexus GSM Poor Write Speeds After Using Almost All Storage Capacity
Galaxy Nexus Storage Performance Over Time & TRIM
Current work around:
fifthelement said:
There is a much better app than lagfix to trim manually. free, ad-free with schedules and lollipop support : https://play.google.com/store/apps/details?id=com.fifthelement.trimmer
Click to expand...
Click to collapse
use AuxLV's LagFix (fstrim) app from Google Play weekly. (highly recommended) :good:
use backfromthestorm fstrim init.d to fstrim on each reboot flashed using CWM recovery, no crontab yet, but much appreciated. (highly recommended) :good:
use your storage wisely, keeping your free space available at 25% available or more to avoid significant slow write degradation. (highly recommended) :good:
return to stock or format /system, /data/, and /cache could help your eMMC storage performance back to normal. (recommended)
mounting the /data partition with discard option and secured erase the free space. (proceed with CAUTION since there's bug brick on some eMMC chip, you may want to check your eMMC chip first using "Got Brickbug ?" app by Chainfire.)
using kernel with fsync off. (NOT recommended)
Keeping your storage at 25% available will make the storage sub-system performance more consistent on SSD, I believe eMMC using same NAND chipset as in SSD less the controller.
Galaxy Nexus eMMC chip list:
VYL00M (insignificant effect)
V3U00M (significant effect)
My take on Galaxy Nexus 16GB storage performance (eMMC VYL00M rev. 0x25):
Return to stock factory image and filling up the storage with 4GB space available:
SW from 7.53MBps to 5.46MBps ~ 27% loss
RW from 0.24MBps to 0.22MBps ~ 8% loss
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Before and after filling up to 389MB space available:
SW from 7.53MBps to 3.91MBps ~ 48% loss
RW from 0.24MBps to 0.23MBps ~ 4% loss
Delete some files to make 4GB space available, and reboot:
SW from 3.91MBps to 6.96MBps ~ 78% gain
RW is the same on 0.23MBps ~ no gain/loss
My take on Nexus 4 16GB storage performance:
Before and after filling up the storage (coming from 5GB and filling it up to 1.2GB space available):
SW from 10 MBps to 4 MBps ~ 60% loss
RW from 1 MBps to 0.39 MBps ~ 61% loss
Did a reboot and the performance is getting better (1.2GB space available, deleted some files left with 2.2GB space available but the performance is more less the same):
SW from 4 MBps to 9.89 MBps ~ 147% gain
RW from 0.39 MBps to 0.51 MBps ~ 31% gain
Using the fstrim app (LagFix for Nexus 7 and HTC One X) and reboot (2.2GB space available):
SW from 9.89 MBps to 9.9 MBps ~ 0.1% gain
RW from 0.51 MBps to 1.07 MBps ~ 110% gain
I attached the cwm packages just for backups. Original scripts are written by backfromthestorm. :good:
Credits (notify me if I forgot to add you here):
ph4zrd
AuxLV
backfromthestrom
JPBeard21
markop90
alangrig
BrianDigital
---
quick thought on samsung eMMC brick bug and how fstrim prolong nand chipset lifespan:
the eMMC brick bug on samsung devices might be related with its own ssd department too. more info about this firmware bug in anandtech site here.
Earlier Samsung told us that all review samples including our three shipped with a pre-production firmware that had a bug in it causing the failures (retail units were shipped with a newer firmware without the bug). At the time we didn't know what exactly was wrong in the firmware, but now we do. When the drive was issued a secure erase command, it would clear all table mapping information at the Address Translation Layer (ATL) but not at the Host Interface Layer (HIL). The data in both layers needs to be up-to-date for the drive operate properly, so when a write request came in, the controller wasn't able to map the data correctly, which caused the firmware to hang. An SSD obviously can't operate without a functioning firmware so from a user's standpoint, it looked like the drive had completely died even though only its firmware was broken.
Click to expand...
Click to collapse
me myself often wonder how come almost all review sites told us to trim in order to prolong the nand chipset lifespan and improve performance. i think i finally found a link to confirm that trim/fstrim does improve nand chipset lifespan by reducing the write amplification.
without trim: storage is nearly full (used, free, and mark as deleted block), and you need to write a bunch of new files which exceed the free available block, the system must do this cycle: read the mark as deleted blocks, erase the mark as deleted blocks, modify the free available block, and write the new files.
with trim: storage is nearly full (used, trully free available), and you need to write a bunch of new files, the system just do this cycle: write the new files, hence less write amplification, longer lifespan and much faster write performance.
the trim command and secure erase are somehow very well explained in this write amplification article on wikipedia here.
TRIM is a SATA command that enables the operating system to tell an SSD what blocks of previously saved data are no longer needed as a result of file deletions or using the format command. When an LBA is replaced by the OS, as with an overwrite of a file, the SSD knows that the original LBA can be marked as stale or invalid and it will not save those blocks during garbage collection. If the user or operating system erases a file (not just remove parts of it), the file will typically be marked for deletion, but the actual contents on the disk are never actually erased. Because of this, the SSD does not know the LBAs that the file previously occupied can be erased, so the SSD will keep garbage collecting them.
The introduction of the TRIM command resolves this problem for operating systems which support it like Windows 7, Mac OS (latest releases of Snow Leopard, Lion, and Mountain Lion, patched in some cases), and Linux since 2.6.33. When a file is permanently deleted or the drive is formatted, the OS sends the TRIM command along with the LBAs that are no longer containing valid data. This informs the SSD that the LBAs in use can be erased and reused. This reduces the LBAs needing to be moved during garbage collection. The result is the SSD will have more free space enabling lower write amplification and higher performance.
The actual benefit of the TRIM command depends upon the free user space on the SSD. If the user capacity on the SSD was 100 GB and the user actually saved 95 GB of data to the drive, any TRIM operation would not add more than 5 GB of free space for garbage collection and wear leveling. In those situations, increasing the amount of over-provisioning by 5 GB would allow the SSD to have more consistent performance because it would always have the additional 5 GB of additional free space without having to wait for the TRIM command to come from the OS.
Click to expand...
Click to collapse
resources:
http://www.anandtech.com/show/6503/second-update-on-samsung-ssd-840840-pro-failures
http://en.wikipedia.org/wiki/TRIM
---
Factory reset via stock recovery, and then use LagFix app or cwm flashable fstrim for optimizing io performance:
AuxLV has made this wonderful app to fstrim your NAND/eMMC storage so it will restore the write performance back to normal after having slow down issues on sequential write and random write due to usage over time. Tested on Nexus 4 and it worked, yay! Do note that this app contains ads from doubleagent and admob as some reported on the original thread.
Take a look at AuxLV LagFix (fstrim) original thread here. AuxLV LagFix (fstrim) FAQs here.
There are two versions of LagFix:
LagFix (fstrim) Premium version - no ads + ability to auto-run trimming on specified schedule. The best choise!
LagFix (fstrim) Free version - trims your memory with one click, has ads, no schedule.
Click to expand...
Click to collapse
backfromthestorm also compiled a flashable script to do fstrim using CWM recovery. take a look at his post here or download the fstrim CWM packages as follows:
fstrim for /system, /data. and /cache here (works on Nexus 4 too!)
fstrim for /data and /cache here
fstrim on reboot here
It seems there's a typo inside the above fstrim init.d script. here's a fix from JPBeard21:
https://www.box.com/shared/l5afni1mxe1wpb2ubw3s
i'm wondering too
Sent from my Galaxy Nexus using xda app-developers app
My sequential write is down to 2.27mb/sec
Never reset my phone to stock and my numbers are all much better than yours. Using Faux kernel with FIOPS scheduler
Looks like someone has been changing ROMs without doing a factory reset...
Sent from my Nexus 7 using xda premium
Teezekel said:
Interesting
Click to expand...
Click to collapse
kizakiyuria said:
i'm wondering too
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
Yeah, i never thought this would happen. Hehe
peachpuff said:
My sequential write is down to 2.27mb/sec
Click to expand...
Click to collapse
Whoa, did you frequent use your storage with lots of small and big file sizes?
I guess you do a lot of write-delete-write cycle like me. I get new hobby to watch 720p movies and hdtv series on this gnex, and total Bit written in my storage were over 16GB, hence the flash memory or nand's write amplication occured and slowed down both sequential and random write speed.
Sdobron said:
Never reset my phone to stock and my numbers are all much better than yours. Using Faux kernel with FIOPS scheduler
Click to expand...
Click to collapse
Now that is awesome! Stock kernel didn't have this tweak on storage performance. hope they will add this feature on next build.
Sent from my Galaxy Nexus
Soldier-2Point0 said:
Looks like someone has been changing ROMs without doing a factory reset...
Sent from my Nexus 7 using xda premium
Click to expand...
Click to collapse
I would point to how much free space is left rather than that wiping everytime a rom is changed....
Sent from my Nexus 7 using Tapatalk 2
---------- Post added at 05:28 AM ---------- Previous post was at 05:26 AM ----------
Sdobron said:
Never reset my phone to stock and my numbers are all much better than yours. Using Faux kernel with FIOPS scheduler
Click to expand...
Click to collapse
Is fsync turned off in faux?
Sent from my Nexus 7 using Tapatalk 2
BrianDigital said:
Is fsync turned off in faux?
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
Is fsync enabled by default on stock kernel? That explains the slow performance on write but with safer data.
Sent from my Galaxy Nexus
Disregard
There is absolutely no point at all in doing this. The increase is so small that its just a waste of time.
Sent from my Galaxy Nexus using xda app-developers app
chrone said:
Is fsync enabled by default on stock kernel? That explains the slow performance on write but with safer data.
Sent from my Galaxy Nexus
Click to expand...
Click to collapse
Yes it is enabled in stock setups, turning it off just leaves the stuff in ram it also tricks benchmarking tests with inaccurate data since its not doing the writing
To the op my stock gnex has results more akin to the after trim results how much storage do you have free
Sent from my Nexus 7 using Tapatalk 2
GldRush98 said:
First off, trim is a command, and more specifically an ATA command. It has nothing to do with eMMC storage. There is no such thing for eMMC.
Second off, eMMC doesn't really need to be trim'ed like SSD's do. The eMMC 4.5 spec did include a discard sub-operation, but it is really not beneficial, especially on our low storage capacity mobile devices.
Click to expand...
Click to collapse
thanks for the heads up. unfortunately a lot of nexus 7 users report slow performance once their sdcard was fulled with data and the regression was pretty much down to below 1Mbps for sequential write. take a look the bugs reported on android open source project.
Smokeey said:
There is absolutely no point at all in doing this. The increase is so small that its just a waste of time.
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
same as the above.
BrianDigital said:
Yes it is enabled in stock setups, turning it off just leaves the stuff in ram it also tricks benchmarking tests with inaccurate data since its not doing the writing
To the op my stock gnex has results more akin to the after trim results how much storage do you have free
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
oh okay, nice to know that.
the available storage left around 3-5gb i guess?
forgot to check when it's down to 5Mbps sequential write. i watched supernatural season 1 to season 6 using gnex before reset to factory image, and the total amount of the serial was more less 42Gb, thus frequent copy-watch-delete thing.
care to vote for bug fix on android open source project as follows? more than 200 people voted this bug to be fix or this feature to be implemented. hope google will listen.
the bug report link, to vote on this following link, click the star button below add comment section at bottom of adroind open source project but report page:
https://code.google.com/p/android/issues/detail?id=37258
Same issue here... If my free space goes below 3gb the phone begins to slow down horribly... Until I factory-reset it....
Random writes <0.50 mb/s on androbench
BrianDigital said:
I would point to how much free space is left rather than that wiping everytime a rom is changed....
Sent from my Nexus 7 using Tapatalk 2
---------- Post added at 05:28 AM ---------- Previous post was at 05:26 AM ----------
Is fsync turned off in faux?
Sent from my Nexus 7 using Tapatalk 2
Click to expand...
Click to collapse
I'm pretty sure I recall reading it's off but I'm not 100% sure...
I usually have about 1 or 2 movies (~700MB or ~1.6GB) on my phone at a time and never had any problems. One day, I felt ambitious to watch a few movies and pretty much got my GNex to under 3GB. Since then, it hasn't been the same.
What I have
GSM Galaxy Nexus
yakjuxw
4.1.1 stock
Unlocked and Rooted
Baseband version I9250XXLF1
Kernel Version 3.0.31-g6fb96c9
Build Number JRO03C.I9250XWLH2
What I've tried
Clearing up movies, camera pictures/videos
Uninstalling recent apps
Clearing app/browser caches
AndroBench Results with 8.14GB available
Sequential Read = 1.97 MB/s
Sequential Write = 0.14 MB/s
Random Read = 0.39 MB/s, 101.47 IOPS(4K)
Random Write = 0.0 MB/s, 1.76 IOPS(4K)
EDIT: Converted from Yakjuxw to yakju using this and now running stock 4.1.2. Now my AndroBench is
26.93 MB/s
12.21 MB/s
8.98 MB/s
0.52 MB/s
markop90 said:
Same issue here... If my free space goes below 3gb the phone begins to slow down horribly... Until I factory-reset it....
Random writes <0.50 mb/s on androbench
Click to expand...
Click to collapse
zero_x3 said:
I usually have about 1 or 2 movies (~700MB or ~1.6GB) on my phone at a time and never had any problems. One day, I felt ambitious to watch a few movies and pretty much got my GNex to under 3GB. Since then, it hasn't been the same.
What I have
GSM Galaxy Nexus
yakjuxw
4.1.1 stock
Unlocked and Rooted
Baseband version I9250XXLF1
Kernel Version 3.0.31-g6fb96c9
Build Number JRO03C.I9250XWLH2
What I've tried
Clearing up movies, camera pictures/videos
Uninstalling recent apps
Clearing app/browser caches
AndroBench Results with 8.14GB available
Sequential Read = 1.97 MB/s
Sequential Write = 0.14 MB/s
Random Read = 0.39 MB/s, 101.47 IOPS(4K)
Random Write = 0.0 MB/s, 1.76 IOPS(4K)
This last AndroBench test is just horrible.
Click to expand...
Click to collapse
same boat here. reset to factory image does format the sdcard and the performance is back to normal again. i hope they do fix this on next build to trigger a command something like TRIM on SSD without having the need to reset to factory image periodically. please vote at the bottom page of page one for Android dev to hear us out regarding this problem. this happens on Nexus 7 as well.
Mounting the relevant partitions with ext4's discard option (as I suggested on code.google.com/p/android/issues/detail?id=39154) seems to fix the problem. You may then fill the filesystem with zeros using dd and simply delete the created file afterwards.
How do you guys regard these results?:
Sent from my Galaxy Nexus using xda premium
I had this problem, and remounting data and cache with discard option on every boot solved this.
alangrig said:
How do you guys regard these results?:
Sent from my Galaxy Nexus using xda premium
Click to expand...
Click to collapse
It's normal.
When your sequential write speed is way below 7MBps then something is not right. The random write will be affected too.
Sent from my Galaxy Nexus
Related
What are the possibilities of using our 2gb of ddr program storage and re allocating it as system ram?
Even if it isn't pure flash (slow speed) I imagine it would be better then nothing, we could always store programs on the sdcard.
Sent from my GT-I9000 using XDA App
android53 said:
What are the possibilities of using our 2gb of ddr program storage and re allocating it as system ram?
Click to expand...
Click to collapse
very good, this post actually explains how to make a swap file (on /cache which is fast nand!).
if you want a swap partition you could a) use part of the 2gb /data partition for a new swap partition which you create in a project-voodoo like manner -> not very easy to do as you would have to repartition /data before boot OR b) just make a 2nd partition on your external sd card to swap on. a lot of people (me included) actually did this with their htc magic.
but to be honest i don't think that you will gain any speed improvements with this, on the contrary your system will be slower an more laggy... i found swap even worse on the magic with ~90mb of user-available-ram. if you want to try it nevertheless, it think the swap file on /cache would be a good start!
jodue said:
very good, this post actually explains how to make a swap file (on /cache which is fast nand!).
if you want a swap partition you could a) use part of the 2gb /data partition for a new swap partition which you create in a project-voodoo like manner -> not very easy to do as you would have to repartition /data before boot OR b) just make a 2nd partition on your external sd card to swap on. a lot of people (me included) actually did this with their htc magic.
but to be honest i don't think that you will gain any speed improvements with this, on the contrary your system will be slower an more laggy... i found swap even worse on the magic with ~90mb of user-available-ram. if you want to try it nevertheless, it think the swap file on /cache would be a good start!
Click to expand...
Click to collapse
If we go for b, will the sgs detect and use the swap partition or do we need to do something else.. I still use my htc magic along side my sgs
Sent from my GT-I9000 using XDA App
i have tried using a swap file, but i didnt c any improvements, and the usage was about 500kb only
I recall that on liquid we managed to use a ramzswap module, which fakes a zipped swap partition in ram. It causes cpu to work a bit more, but it was still efficient.
Elvoski said:
If we go for b, will the sgs detect and use the swap partition or do we need to do something else.. I still use my htc magic along side my sgs
Click to expand...
Click to collapse
you would have to repartition our external sd to have a second (linux swap) partition.
then use mkswap to set the partition up and after that call swapon. swapon has to be redone every time you restart but you could place it in a playlogos1 script to automate that.
captive said:
I recall that on liquid we managed to use a ramzswap module, which fakes a zipped swap partition in ram. It causes cpu to work a bit more, but it was still efficient.
Click to expand...
Click to collapse
compcache?! ... i guess this would also be a good trade off for our galaxy s because the cpu is definitely not the bottleneck here...
btw. a good read about swap & compcache from the cyanogenmod wiki: swap & compcache
android53 said:
What are the possibilities of using our 2gb of ddr program storage and re allocating it as system ram?
Sent from my GT-I9000 using XDA App
Click to expand...
Click to collapse
Bad, bery bad idea, MoviNand is not in any way releated to DDR. It's waaaay slower.
Also, RAM is designed for virtually unlimited data read/write counts.
NAND memory is not.
What would be the benefit of using swap space? Nothing. Data is being read/written in filesystem in the end. No improvement in performance. (It could be seriously degraded).
This behavior is totally against Android core design principles. Android doesnt use swap because it doesnt need to. Programs not fitting into "RAM" are being closed with their state remembered. When program is re-launched it is loaded from filesystem and its state is being restored.
If we had "swap" space, it would become really messy. Just imagine:
System wants to close program X, resident in swap, it needs to:
- restore program from swap to RAM (talk about additional ram needed)
- close program, resulting writing state to FS.
i was talking about this sort of thing with Ryza and Voodoo guy they said it was too much work
i'm forward with the idea of using a Swap drive in RAM or external SD
to prevent over usage on the internal SD
This means external SD would need to be powered up at all times -> battery drain (it is present with APPS2SD - or whatever this name was)
Wuld this mean that we would have extra ram available for running apps...like SGS task manager will show more than 311Mb RAM ?
If this is the case then I am very interestied, since I don't care about speed so much. I just need to run an app that currently can not run due to out-off-memmory (needs 130Mb of RAM) for pure presentation purposes
There is a app in market called swapper2 which can make use of the swap partition or creates a swap file for use. I had been using this app since my HTC MAGIC and now on SGS.
I'm currently using swap partition that had been created earlier in my class 6 SDCard. Works on both eclair or froyo kernels on SGS. So far I am not complaining, with swappiness 20, there is not much of memory hog or lag due to opening too many apps or single memory hogging apps (like flash on browser) on my XXJPK, the swap memory gets allocated and deallocated as you can tell from the swapper info feature.
But the battery effects is something to think about though, sdcards are cheap so I don't mind sacrificing it. The other way is to create a swap file on the rfs and use it if you value your sdcard. The screenshot provided is a normal usage of my device with a few apps running at background (Still gonna be 300+ RAM, nothing magical about it though) and I had also used minfree tweak on the kernel.
You can try and see if it helps in terms of performance for a few days. I cant vouch for the swapper a lot as I'm using it myself - I am more uncomfortable without it though. What Xan said does makes sense but there are rare times when the things that doesn't makes sense gives us surprises.
A good read up and comments from people who had tried and used it in different scenarios...
http://zerocredibility.wordpress.com/2009/08/24/why-android-swap-doesnt-make-sense/
Sent from my GT-I9000 using Tapatalk
Currently development is paused - anyone interested in the source code write me a pm.
This app is aiming to give you better numbers for comparing different filesystems used in various lagfixes. It should also work for different phones, so that we can compare performance between them.
Currently this is a betaversion, so just try it out if you have a backup of your system. Even if nothing should happen to your system, i cannot guarantee for it
PLEASE UNINSTALL PREVIOUS VERSIONS BEFORE TRYING A NEW ONE
Usage: Run the app, change the number of iterations in the options menu, and run Benchmark Filesystem. View your Results with "Last Benchmark Summary".
Reading the detailes values: Example: File writes 10k: 5378(53) kB/s
- The name describes the Test - here writing Files with 10kBytes size
- first number - here 5378 - is the mean value result - in this case the write speed in kBytes per second
- number in brackets: the approximate error (+-) of the mean value calculated.
The first test after a fresh installation can get somewhat faked numbers, repeat it at least two times to make sure to have reproducable values. If one value has a very large error compared to the others the reason could be another app doing something - just repeat the benchmark to see if its real.
Changelog 0.8:
- Refined Stress test and details
- FAQ added
- Logfile can now be copied (Longpress)
- Logfile structure changed for better overview
Changelog 0.7:
- Comparison bar chart added
- More detailed overall Score
- renamed it for broader future audience
- new icon set
- Minimum iterations is now 4
- the best and worst iteration are not taken for calculations - prevent statistical outliners
- Logfile lies now under TAPBenchmark
- Last benchmark numbers can be copied for fast pasting into this forum (Longpress)
Changelog 0.6:
- Additional Stresstest (Parallel read/write)
- Overall Benchmark Score introduced (has to be refined in future)
- Time for a Single Test can be changed to increase accuracy (maybe)
- Free space can be checked to ensure there is enough (no check before start yet)
- Write and Read test refined (data is now written/read to/from different files)
- Rewritten to be Android style (back-button working now as it should for example ...)
Changelog 0.5:
- Tests calculate readable values (Writes/s or kByte/s)
- Number of iterations can be changed (between 2 and 20) - standard is now 10
- Number of Repetitions per Test is automatically ajusted in the beginning so that each iteration takes approx. 1s - 7 tests with 10 iterations takes always approx 70s
- File read/write overhead is calculated: This is done by compare read/write speed of the 10k and 1M Tests under the assumption that the 1M tests give approx. the raw I/O speed. The number can be interpreted as additional time needed to read/write a file regardless of the size, which has to be added to the time it takes to read/write the file data itself.
- Display will stay on during the benchmark.
- sdcard test has been disabled- lets concentrate on /data first.
Reporting bugs and your Benchmark numbers is very welcome, i will include the numbers into the program for comparison. I will try to improve the tests to be as meaningful as possible, so post any ideas you have for improving it.
I think its a great idea.
Sgs don't have any good benchmark program that's test the hardware that's in the sgs.
So it would help alot when tweaking the phone..
Sent from GT-I9000 jpo. My own kernel for z4mod and with 342MB Ram
Well, looks like i will start myself
I thought about testing time needed for writing/reading/deleting files with different filesize - 10k,100k,1M to start with. As far as i have seen /data and /sdcard can be accessed easily - and testing /sdcard would give one numbers about the sdcard. If i use a database, is this automatically stored on /dbdata, so that one can measure speed there? What about the other partitions - how can i access them?
Sounds like a good idea.
You need to use root access so you can make them write access.
Sent from GT-I9000 jpo. My own kernel for z4mod and with 342MB Ram
I would vote this one up.
Work is in progress - database read write benchmarks work already - in the mean time i have found a nice benchmark in the market: rl sqlite benchmark - it tests just sqlite performance but could give you already some numbers.
I will update this thread as soon as i have a beta version available for you ...
Sent from my GT-I9000 using XDA App
Sounds nice.
Keep me informed ;-)
Sent from GT-I9000 jpo. My own kernel for z4mod and with 342MB Ram
What about include a tool to detect that filesystem corruption caused by some lagfixes?
I think you could expand this solution to check the main things that concerns SGS modders, not just a bechmark... but I don't know. I'm not a developer, so I can't imagine the amount of work something like this would take...
I'm gonna sign up for this one.
Count me in as well!
So,a first beta version is available. I have tested it on my own device without problems, but i cannot guarantee for anything, so please backup your system before trying it. But since its just a simple app, it should be safe.
Currently there are no progress bars, and since the test takes some seconds, dont get nervous if nothing happens for some time when you start the test. It should not take longer then 30s ...
Please report any bugs and report your values - i have already included my ones with RFS+EXT2 with OneClickLagFix. I think the database values are somewhat fake with an loopback enabled, so if you have any ideas for better tests please post.
Currently only the internal memory is tested, i guess its /data? I have a lot of ideas for improvements and will post a new version as soon as mayor changes are finished.
Please report any bugs you find.
EDIT: What the File write test means: Time needed to Read/Write a file with size 10k/1M 20 times.
EDIT: Removed file because its outdated ...
Seems to work.
But it one thing you need to do.
All data on test you do must be stored so you can compare them.
Then you can use it better;-)
I progressbar or something that shows that the program do something.
Maby an online database to be able to compare with others. But that's hard for its alt more data that need to be there if it shall be usefully.
Sent from GT-I9000 jpo. My own kernel for z4mod and with 342MB Ram
DamianGto said:
Seems to work.
But it one thing you need to do.
All data on test you do must be stored so you can compare them.
Then you can use it better;-)
I progressbar or something that shows that the program do something.
Maby an online database to be able to compare with others. But that's hard for its alt more data that need to be there if it shall be usefully.
Sent from GT-I9000 jpo. My own kernel for z4mod and with 342MB Ram
Click to expand...
Click to collapse
Yes storage of tests is noted, currently only the last test is stored. Progressbars have just been implemented Online database maybe, but first lets refine the test we want to do ...
What are actually the numbers you get? Mine are this:
DBWrite: 153 ms
DBRead: 74 ms
DBDelete: 64 ms
File Write 10k: 43 ms
File Write 1M: 1627 sm
File Read10k: 37 ms
File Write 1M: 1439 ms
where the only number differing more then 20% from run to run is the DBWrite - which i think is because of the loopback EXT2 of the OCLF.
Sounds good.
Oclf will always give false values.
I also think its an old way and you should try an kernel instead with real lagfix.
The values I got is higher then the ones you got.
Maby you should add 100k test to.
Sent from GT-I9000 jpo. My own kernel for z4mod and with 342MB Ram
Here the improved version - with progressbar and slightly adjusted tests. This should also work for 2.1 and other phones, feedback welcome!
@DamianGto OCLF is not the best way to go, i know, i am looking forward to z4mod and going to native EXT2 ... but not right now ...
My values for the new test:
DBWrite: 283ms (50 SQL Inputs)
DBRead: 188ms (50 SQL Selects)
DBDelete: 208ms (50 SQL Deletes)
File Write 10k: 118ms (50 Writes)
File Write 1M: 834ms (10 Writes)
File Read10k: 101ms (50 Reads)
File Write 1M: 761ms (10 Reads)
EDIT: Removed the file because its outdated ...
That was better
database score seems little strange.
I got about 10 times higher then yours. But i guess that is Oclf weird thing i have seen in other test program.
Sent from GT-I9000 jpo. My own kernel for z4mod and with 342MB Ram
So have just undone OCLF therefor stock RFS:
Dbwrite: 3956ms
Dbread: 366ms
Dbdelete: 366ms
Filewrite10k: 3223ms
Filewrite1m: 5587ms
Filereads10k: 187ms
Filereads1m: 783ms
Mostly no difference at reads of large files, huge difference on writes, as expected ...
Sent from my GT-I9000 using XDA App
Peacemanibk said:
Here the improved version - with progressbar and slightly adjusted tests. This should also work for 2.1 and other phones, feedback welcome!
@DamianGto OCLF is not the best way to go, i know, i am looking forward to z4mod and going to native EXT2 ...
Click to expand...
Click to collapse
Ext2 is now available in the SpeedMod kernel. I'm using it at the moment.
Phandroid said:
Ext2 is now available in the SpeedMod kernel. I'm using it at the moment.
Click to expand...
Click to collapse
Good. At last they understand how good ext2 is.
Sent from GT-I9000 jpo. My own kernel for z4mod and with 342MB Ram
Cmon guys tell me your benchmark numbers!
Btw. Right now the benchmark ia done by opening-writing/reading-closing a file x-times using fileoutputstream. Any opinion to other tests?
Sent from my GT-I9000 using XDA App
So, it turns out the /preload partition is 500 megs of almost unused space, just to show us a video of Asphalt. So, how about turning it into swap space to almost double the effective amount of memory you have? To use this mod, you must be rooted, and have busybox installed. I recommend the stericson busybox installer https://play.google.com/store/apps/details?id=stericson.busybox&hl=en
I would like feedback on whether or not it actually speeds up the device, especially when running graphics-intensive games, and also effects on battery life.
How to install:
1.Be rooted.
2. Get busybox. If you don't already have it, you can get it here https://play.google.com/store/apps/details?id=stericson.busybox&hl=en
3. You must have init.d support. This is built into my NardROM but you can also flash the file attached to this post.
4. Flash the script installer, attached below. NOTE: This will wipe your /preload partition. You can make a nandroid before you perform this step but CWMR doesn't back up /preload. Back up anyway
5. If it's successful, you will see something like the following screenshot when you open a terminal window and execute "free". Notice the swap being used. If you don't have swap enabled it will read 0 available.
To disable the mod:
1. Delete the script from /system/etc/init.d
2. Reflash your Asphalt video from a backup
To disable init.d:
1. Delete /system/etc/install-recovery.sh, /system/etc/init.d (entire folder), /system/bin/sysinit, and /system/xbin/run-parts
Disclaimers:
Using nand memory as a swap can significantly reduce its life. Your phone's internal memory will wear out in years rather than decades
A lot of people argue using Android swap works against the built in memory management of the Dalvik machine
http://forum.xda-developers.com/showthread.php?t=1504774
This is awesome, glad to see people spending time on this device
Tappin' Typin'
'' /vendor '' also has 590,56 Mbyte of space..
what kind of data is there? there are some folders called ''multi_pose_face_landmark_detectors.3'' and ''yaw_roll_face_detectors.3'' ? is this the carrierIQ stuff?
After deleting everything on that partition it says 395,95 mb used, 194,61 mb free.
ludacris1 said:
'' /vendor '' also has 590,56 Mbyte of space..
what kind of data is there? there are some folders called ''multi_pose_face_landmark_detectors.3'' and ''yaw_roll_face_detectors.3'' ? is this the carrierIQ stuff?
After deleting everything on that partition it says 395,95 mb used, 194,61 mb free.
Click to expand...
Click to collapse
I think it's device-specific info for face unlock to compensate for various things like the angle you're holding the phone at and the distance away from your face. And if you'll look a little more closely, you'll find /vendor is symlinked from /system/vendor, it's not actually a separate partition. You should probably put those files back if you want face unlock to work.
Technically I just downloaded some ram
Sent from my SGH-I927 using xda app-developers app On Ics
FYI, this could be a potential source of serious slowness. Swap isn't anywhere near as fast as real RAM.
I wouldn't do this unless you're legitimately having issues you can directly attribute to running out of RAM. It may be useful as Android marches on and demands more and more RAM but for ICS we're already a good clip above the recommended specs.
Same thing I was thinking. I have more than enough RAM but if by some miracle we get something past JB that uses a lot of RAM I'll do this. Nice work on it though!
sent from my captivate glide running ICS (NardROM 0.4 Rooted)
roothorick said:
FYI, this could be a potential source of serious slowness. Swap isn't anywhere near as fast as real RAM.
I wouldn't do this unless you're legitimately having issues you can directly attribute to running out of RAM. It may be useful as Android marches on and demands more and more RAM but for ICS we're already a good clip above the recommended specs.
Click to expand...
Click to collapse
Waiting for the comparison,then
mewatashiakumoi said:
Waiting for the comparison,then
Click to expand...
Click to collapse
So with this hack having been out a couple months now, how are the reviews? Performance increase? Fewer slow downs?
pm2gonzales said:
So with this hack having been out a couple months now, how are the reviews? Performance increase? Fewer slow downs?
Click to expand...
Click to collapse
1) this is not a hack, this is a simple tweak
2) swap file is ALWAYS has a performance decrease effect, no matter what (desktop PC, android phone). The only reason of use is when the device has no enough RAM, and the background processes shall be kept elsewhere
3) android has it's own RAM managing system and methods, simply stick to that as only that will gives you the best performance and user experience
4) "slowdown" occurs when the device runs out of free RAM and starts closing background applications to give everything to the foreground app. When you close the heavy resource use foreground app witch caused android to close every possible background apps, the phone reloads them (launcher, live wallpaper, app drawer, widgets, user apps, etc...) and this is what causes a temporary slowdown, and this is unavoidable, no matter if you use swap or not.
I have found out that some phones are slow because of a bug in Android 4.2. I have a way to determine if you have the bug.
1. Download Androbench: https://play.google.com/store/apps/details?id=com.andromeda.androbench2
2. Execute the test (just press on test all)
3. Is the "random write" speed under 2 MB/s? Then you have the bug.
A possible solution for it is (it is a solution for the Nexus 7 but since it is the same bug it may or may not work on the Galaxy Nexus):
1. Fill up the storage completely
2. Format it
It could be fixed. Let me know if it works.
Sent from my Galaxy Nexus using XDA Premium HD app
https://play.google.com/store/apps/details?id=com.grilledmonkey.lagfix use this
send via Samsung Galaxy Nexus with Tapatalk 4 Beta
My random write speed is 0.2 MB/s whether I use the lagfix or not. Running PA 3.65 and AK SKL256. This is pathetic.. :crying:
jaizero said:
My random write speed is 0.2 MB/s whether I use the lagfix or not. Running PA 3.65 and AK SKL256. This is pathetic.. :crying:
Click to expand...
Click to collapse
0.16MB/s before "lagfix", 0.16MB/s after "lagfix".
Edit: I will try the OP's fix later tonight when I get home.
Edit2: By "lagfix" I meant "Lagfix Free" the fstrim implementation on Android mentioned by DJxSpeedy above.
I thought this issue was due to flash degredation?
I have issues with my gnex. Keeps freezing and turning off whenever I do anything really. Gets quite hot as well.
Tried 2 resets and it gets better but comes back again shortly.
Sending it to Samsung for warranty fix.
The nexus 7 does lag and slowdown at times. But a reboot usually solves it. That or freeing up space. I got about 6 gigs free now from the 32GB.
Sent from my HTC One using xda premium
voyager_s said:
I have issues with my gnex. Keeps freezing and turning off whenever I do anything really. Gets quite hot as well.
Tried 2 resets and it gets better but comes back again shortly.
Sending it to Samsung for warranty fix.
The nexus 7 does lag and slowdown at times. But a reboot usually solves it. That or freeing up space. I got about 6 gigs free now from the 32GB.
Sent from my HTC One using xda premium
Click to expand...
Click to collapse
I was getting Random Write speeds of 0.17 MB/sec through AndroBench. I just tried LagFix right now and it did NOT fix it for me. Post-LagFix, AndroBench reported 0.15 MB/sec. No wonder my phone has been insanely slow. Sigh...
Mine gets realy hot, too. Even if I underclock the phone's CPU and GPU, it still gets hot around the top half of the phone (both sides).
With dynamic fsync enabled in Trickster Mod my random write jumps from 0.2 MB/s to an astonishing 290.14 MB/s. Not sure if these are erroneous due to caching or not. But, that is a significant increase.
Edit: With dynamic fsync enabled I have seen significant increases throughout the benchmark.. Any ideas on why this is occurring?
jaizero said:
With dynamic fsync enabled in Trickster Mod my random write jumps from 0.2 MB/s to an astonishing 290.14 MB/s. Not sure if these are erroneous due to caching or not. But, that is a significant increase.
Edit: With dynamic fsync enabled I have seen significant increases throughout the benchmark.. Any ideas on why this is occurring?
Click to expand...
Click to collapse
I'm not an expert in that area, but I have to wonder if there is caching going on. That number seems too good to be true. However, if true, that is an awesome number.
Sent from my Galaxy Nexus using Tapatalk 2
jaizero said:
With dynamic fsync enabled in Trickster Mod my random write jumps from 0.2 MB/s to an astonishing 290.14 MB/s. Not sure if these are erroneous due to caching or not. But, that is a significant increase.
Edit: With dynamic fsync enabled I have seen significant increases throughout the benchmark.. Any ideas on why this is occurring?
Click to expand...
Click to collapse
Yeah, don't trust it as it doesn't really speed up your storage. Any fsync off/dynamic fsync on benchmarks can be disclaimed as not being real speeds. Both these features disable the fsync function to maintain filesystem integrity. Dynamic fsync actually enables fsync when the screen is on and disables it when the screen is off.
About the OP's report. 2MB/s is amazing for random writes at Androbench's default 4KB. I barely get that on my HTC One which has a faster emmc chip in it in the Galaxy Nexus. 0.2MB/s is more common for the Galaxy Nexus so 0.15 is actually not that far off. There is a whole thread dedicated to fstrim and the lag issue and it mentions lagfix is more detail. 2MB/s is impossible with Androbench's default settings so I don't think slow random write speeds are the only reason for Android 4.2.2 lag. I actually looked into that thread in December and some testing and research concluded that the I/O isn't the only reason and a fresh install won't improve it that much unless you have the emmc performance bug where it slows down a lot when the storage fills up.
I think you have your description of dynamic fsync reversed. When the screen is off, fsync is on. Screen on, fsync off. I think Trickstermod describes it as when enabled and screen on, fsync operation is asynchronous, screen off it is commited synchronously. But I may be wrong, you are a great kernel developer so you know you're stuff.
tiny4579 said:
About the OP's report. 2MB/s is amazing for random writes at Androbench's default 4KB. I barely get that on my HTC One which has a faster emmc chip in it in the Galaxy Nexus. 0.2MB/s is more common for the Galaxy Nexus so 0.15 is actually not that far off. <snip> I actually looked into that thread in December and some testing and research concluded that the I/O isn't the only reason and a fresh install won't improve it that much unless you have the emmc performance bug where it slows down a lot when the storage fills up.
Click to expand...
Click to collapse
I do agree with this. I only get 0.16MB/s and my phone is as snappy as ever. The only time I notice slowdowns are with app updates (way slower than my wife's Galaxy S3) and backups (again the S3 is way faster). Which, to me, is indicative of slow media. I am always on the latest CM stable. (10.1.2 as I write this.) I use no other mods at this time.
---------- Post added at 12:42 PM ---------- Previous post was at 12:38 PM ----------
As I posted the previous post. I did remember that if I let apps run default my Nexus bogs like crazy. Much more so than the S3. I use Greenify (I previously used Autostarts) to keep this in check.
mrgnex said:
I have found out that some phones are slow because of a bug in Android 4.2. I have a way to determine if you have the bug.
1. Download Androbench: https://play.google.com/store/apps/details?id=com.andromeda.androbench2
2. Execute the test (just press on test all)
3. Is the "random write" speed under 2 MB/s? Then you have the bug.
A possible solution for it is (it is a solution for the Nexus 7 but since it is the same bug it may or may not work on the Galaxy Nexus):
1. Fill up the storage completely
2. Format it
It could be fixed. Let me know if it works.
Sent from my Galaxy Nexus using XDA Premium HD app
Click to expand...
Click to collapse
I just ran this test on my Galaxy Note 8 running stock rooted Android 4.1.2. And got a result of 1.42mb/s random write. So there seems to be more to this than Android 4.2
Sent from my GT-N5110 using xda app-developers app
t1.8matt said:
I think you have your description of dynamic fsync reversed. When the screen is off, fsync is on. Screen on, fsync off. I think Trickstermod describes it as when enabled and screen on, fsync operation is asynchronous, screen off it is commited synchronously. But I may be wrong, you are a great kernel developer so you know you're stuff.
Click to expand...
Click to collapse
That's what i said. Dynamic fsync disables fsync - off - with the screen on and enables it - on - once the screen is on. The regular fsync is a manual toggle.
Dynamic fsync from faux is off by default in my kernel so fsync would function normally with this off.
Sent from my HTC One using Tapatalk 2
ahh, got ya.
Is this ok with the default settings?
tiny4579 said:
Yeah, don't trust it as it doesn't really speed up your storage. Any fsync off/dynamic fsync on benchmarks can be disclaimed as not being real speeds. Both these features disable the fsync function to maintain filesystem integrity. Dynamic fsync actually enables fsync when the screen is on and disables it when the screen is off.
About the OP's report. 2MB/s is amazing for random writes at Androbench's default 4KB. I barely get that on my HTC One which has a faster emmc chip in it in the Galaxy Nexus. 0.2MB/s is more common for the Galaxy Nexus so 0.15 is actually not that far off. There is a whole thread dedicated to fstrim and the lag issue and it mentions lagfix is more detail. 2MB/s is impossible with Androbench's default settings so I don't think slow random write speeds are the only reason for Android 4.2.2 lag. I actually looked into that thread in December and some testing and research concluded that the I/O isn't the only reason and a fresh install won't improve it that much unless you have the emmc performance bug where it slows down a lot when the storage fills up.
Click to expand...
Click to collapse
Actually, the HTC One has also been known to have this issue.
Well I got higher than 2 MB/s so I thought that a speed below that would couse the lag. Apparantly I am wrong. I have read it somewhere but it seems theyre wrong. At random write I het around 200 MB/s and random read around 10 MB/s.
Sent from my Galaxy Nexus using XDA Premium HD app
Try Forever Gone: https://play.google.com/store/apps/details?id=com.kovit.p.forevergone
Increased performance on my Nexus 7 by a ton. It's still running on my Galaxy Nexus, but I expect the same results
Both my gnex and my N7 are fast. I'm starting to think it's all user side problems.
Sent from my Nexus 7 using xda premium
Ok,
First it started on 4.3, it was very slow, but then i tried lagfix fstrim it did a little difference, but it didn't fix storage performance speeds, i certainly gave up hope and kept using lagfix to get rid of lags.
But then i flashed KitKat 4.4 (CM) Mpokang Kernel,did a little recycling on memory, and filled it again to 2 - 2.5 gb free space.
After a andro bench test i get awesome write speeds but poor read speeds. same applies even if i fill the whole storage to 1gb or 500mb left.
I want to do a complete factory reset, and format whole storage maybe then it will get fixed.
So anyone had a similar problem ?