[REF] The truth about flash [RFS][EXT4][Bad Blocks][Real Numbers][noatime]

Search This thread

plapczyn

Retired Recognized Developer
Background:
Ok, so I write flash drivers for a living, so I would consider myself somewhat knowledgeable regarding flash technology.

The flash is erased in 128k blocks and written in smaller pages. Data, once written, cannot be changed until you erase, so the FS will write to another page and invalidate the current page. The 100k program/erase cycle count is on a per block basis. It is not being erased every time you write a file, so calm down, your phone isn't going to die. The 10 year data retention time that people are quoting has nothing to do with this. It is how long once programmed...and not changed...data is guaranteed to be valid for.

The only thing that you need to remotely consider...and needs to actually be verified, is whether RFS actually writes to the file system more or less than EXT4, and how much more. The data wear leveling is done on a lower layer than the file system and Dameon87 already confirmed both RFS and EXT4 are using the same sector translation layer.

Sources:
XDA Post linking RFS documentation: http://forum.xda-developers.com/showthread.php?t=801223
Reliability: http://www.samsung.com/global/busin...s/fusionmemory/Products_FAQs_Reliability.html
Datasheet: http://www.datasheetcatalog.org/datasheets2/12/1248447_1.pdf
Attached are app notes on RFS.

Regarding RFS:
RFS Programming Guide said:
STL Block Device Driver: This block device driver is used to provide driver functions for the device files /dev/stl0/*, /dev/stl1/* and so on. Since there is FTL between this block device driver and BML, it is allowed to perform random write requests and write requests are handled atomically. Thus any read-write file system (e.g. RFS) can run on this block device driver.

STL (Sector Translation Layer): translates a logical address from the file system into the virtual flash address. It internally has wear-leveling during the address translation.

Regarding EXT4:
EXT4 supposedly buffers more data before writing, thus in theory should require less program/erase cycles. This could in theory explain why people claim better battery life using EXT4. To program/erase flash, you must temporarily raise the flash voltage...this is why flashing ROMs and using ODIN drain your battery like crazy...and why you should always flash with a battery near 100%. This point is of course mute if there is no wear protection. If EXT4 is using the Samsung STL driver, the wear leveling should be implemented exactly the same as in RFS.

Regarding Bad Blocks:
It is typical to have some bad blocks in large flash arrays direct from the factory. It is normal and part of the manufacturing/validation process.
http://www.samsung.com/global/business/semiconductor/products/fusionmemory/Products_FAQs_Reliability.html said:
SAMSUNG guarantees the first block will operate properly during the 100K P/E cycle under normal conditions. On the other hand, other blocks can be invalid as long as the total number of bad blocks doesn't exceed 2% of all blocks.

Samsung Datasheet said:
The device may include invalid blocks when first shipped. Additional invalid blocks may develop while being used. The number of valid blocks is presented
with both cases of invalid blocks considered. Invalid blocks are defined as blocks that contain one or more bad bits. Do not erase or program factory-marked bad blocks.

Invalid blocks are defined as blocks that contain one or more invalid bits whose reliability is not guaranteed by Samsung. The information
regarding the invalid block(s) is so called as the invalid block information. Devices with invalid block(s) have the same quality
level as devices with all valid blocks and have the same AC and DC characteristics. An invalid block(s) does not affect the performance
of valid block(s) because it is isolated from the bit line and the common source line by a select transistor.
The system design
must be able to mask out the invalid block(s) via address mapping. The 1st block, which is placed on 00h block address, is fully guaranteed
to be a valid block.

Within its life time, additional invalid blocks may develop with the device. Refer to the qualification report for the actual data.The following
possible failure modes should be considered to implement a highly reliable system. In the case of status read failure after
erase or program, block replacement should be done. Because program status fail during a page program does not affect the data of
the other pages in the same block, block replacement can be executed with a page-sized buffer by finding an erased empty block and
reprogramming the current target data and copying the rest of the replaced block.

Check your bad datablocks by doing this...
Code:
adb shell
su
cat /proc/L*/bmlinfo

You will probably have a few. I have 3. The block size is 128KB. 512MB/128KB = 4096 blocks (thats why they are using the bottom blocks in the 4000 range for the 2% coverage. 2% of 4096 is apx 81 bad blocks. But don't worry. You would have to get about 3 bad blocks per month for 2 years straight before a failure.

Conclusion:
Now of course the best way to extend the life of the flash is to use the SD card for partitions that get continually written to like /data...and don't flash new roms 100 times a day for 2 years. But you really don't have to worry about the dreaded flash fairy coming and breaking your phone after a week. Since FAT writes to the fixed location file allocation table over and over, Samsung already has the wear leveling in place. Moreover, RFS adds journaling and posix commands to FAT and was mounted with atime. Most likely, it was doing MORE file IO than EXT4. Below is a link to some info on EXT4 disk writes. Clearly using noatime and journaling off is the best option for flash with regard to longevity, however, the difference isn't as big as you would think.

Further Reading:
The Truth About RFS (warning lacks citation): http://forum.xda-developers.com/showthread.php?t=799931
EXT4 Performance testing: http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/
 

Attachments

  • RFS_130_Porting_Guide.pdf
    414 KB · Views: 83
  • rfs_v12_application_note.pdf
    247.6 KB · Views: 85
Last edited:

lviv73

Senior Member
Mar 3, 2010
1,529
91
Buffalo NY
So in your opinion even if Ext4 degregades nand lets say 2-3 times faster than RFS,would Epic still function normaly with heavy daily use for 2-3 years?
 

kenvan19

Senior Member
Dec 7, 2010
3,562
540
Code:
EXT4_lifecycle = RFS_flash_lifecycle * (EXT4_write_cycles/RFS_write_cycles)

Thank you so much for your expertise on this matter plapczyn and for clearing up this dispute! I would add a thanks to you but alas, I have used all of mine today hehe! I suppose I may be one of the few (or many, who knows?) people who really enjoy reading technical responses that are beyond my personal understanding as they generally allow me to glean information that was previously out of my grasp! I really appreciate your detailed response!
 

msponsler

Senior Member
Sep 1, 2010
103
24
Harrisburg, PA
Great information plapczyn.

But I think a lot of this stems to how ext4 behaves compared to rfs.

To be frank, I know very little about rfs beyond the fact that it's basically vfat with journaling support. To be honest, that sounds horrible...

ext4 on the other hand, I've got a decent grasp on it:
The real danger of writes with ext4 on nand flash comes from the meta-data blocks. Luckily in ext4 (unlike ext3), the meta-data blocks can be (and are) moved. The 128MB per block (in a 4KB block file system) restriction is removed (each 128MB block required a dedicated meta-data block).
Meaning, mke2fs (part of ext4) can MOVE the meta-data blocks around outside the large virtual block group as the are grown and shrank. Which means that the meta-data blocks aren't constantly written to the same spots, spreading out the meta-data writes across the storage.

The delayed allocation feature of ext4, in addition to the block allocator (mballoc) significantly reduces fragmentation -- in addition to vastly increasing performance. Decreased fragmentation means less move(); rename(); write(); delete(); operations to fit your data in the allocated blocks, thus decreasing wear on the nand (re-writing & updating meta-data) -- atleast in comparison to ext2/ext3. See the part above on how I know very little about rfs, I can't speak on how rfs handles fragmentation and block allocation. But considering how fragmented vfat gets...

But let's put some stuff into perspective:

Does ext4 create more I/O overhead (delete(); / write(); operations specifically) than rfs? Possibly. Some very valid questions were raised -- and questions like this NEED to be raised and debated.

journaling doesn't need to be enabled on your phone. That will alleviate a great deal of the writes if you are worried about it.

Is ext4 a good idea for nand flash on Linux running a database from a reliability stand point? Hell. No.

But a lot of writes in android's /system directory running ext4? Not likely. Sure it would wear out, but probably after a few years. Besides, doesn't samsung have wear-leveling in the controller to the nand? All Android and ext4 sees is the logical level. Which would render this whole argument moot.
 
  • Like
Reactions: 816jared

kenvan19

Senior Member
Dec 7, 2010
3,562
540
Great information plapczyn.

But I think a lot of this stems to how ext4 behaves compared to rfs.

To be frank, I know very little about rfs beyond the fact that it's basically vfat with journaling support. To be honest, that sounds horrible...

ext4 on the other hand, I've got a decent grasp on it:
The real danger of writes with ext4 on nand flash comes from the meta-data blocks. Luckily in ext4 (unlike ext3), the meta-data blocks can be (and are) moved. The 128MB per block (in a 4KB block file system) restriction is removed (each 128MB block required a dedicated meta-data block).
Meaning, mke2fs (part of ext4) can MOVE the meta-data blocks around outside the large virtual block group as the are grown and shrank. Which means that the meta-data blocks aren't constantly written to the same spots, spreading out the meta-data writes across the storage.

The delayed allocation feature of ext4, in addition to the block allocator (mballoc) significantly reduces fragmentation -- in addition to vastly increasing performance. Decreased fragmentation means less move(); rename(); write(); delete(); operations to fit your data in the allocated blocks, thus decreasing wear on the nand (re-writing & updating meta-data) -- atleast in comparison to ext2/ext3. See the part above on how I know very little about rfs, I can't speak on how rfs handles fragmentation and block allocation. But considering how fragmented vfat gets...

But let's put some stuff into perspective:

Does ext4 create more I/O overhead (delete(); / write(); operations specifically) than rfs? Possibly. Some very valid questions were raised -- and questions like this NEED to be raised and debated.

journaling doesn't need to be enabled on your phone. That will alleviate a great deal of the writes if you are worried about it.

Is ext4 a good idea for nand flash on Linux running a database from a reliability stand point? Hell. No.

But a lot of writes in android's /system directory running ext4? Not likely. Sure it would wear out, but probably after a few years. Besides, doesn't samsung have wear-leveling in the controller to the nand? All Android and ext4 sees is the logical level. Which would render this whole argument moot.

To clarify a single point, and I apologize if this is a stupid question, I have read and heard that disabling journaling does increase the risk of corrupted data but how real is that risk (meaning how much of a danger is it really?) and if data is corrupted would it effect the ability of the system to function or would it merely be 'cosmetic' (for lack of a better word) corruption?
 

h2g2

Senior Member
Dec 31, 2010
73
14
Wear leveling for the OneNAND is implemented in software, not in hardware, in the STL as plapczyn mentioned in his post. From what I can tell, STL is responsible for exposing the OneNAND chip as a block device and from there, you can format the device using RFS, YAFFS, EXT4 or whatever.

Another note here is that the type of wear-leveling that RFS and YAFFS do is called dynamic wear leveling which means wear-leveling is only done on write ops as I understand it. SSDs use static wear leveling that is capable of moving, for example, data from blocks that change rarely over to blocks that change frequently in an effort to give said blocks a chance to "rest". The wear-leveling in RFS and YAFFS doesn't do this.

In addition, SSDs include extra NAND chips and only expose some percentage of the total capacity so that extra blocks are available for wear leveling. From what I understand, the OneNAND chip has no "extra" capacity for this purpose. This means that the more total space you allocate with static data, the quicker you'll run into problems because you'll be reusing a smaller set of blocks over and over for writes. This can be overcome with careful partitioning and, of course, maintaining a reasonable amount of free space.

But, dynamic wear leveling is used in USB memory sticks and most flash memory cards as well (including Micro SDHC cards which is why they can stay on FAT/FAT32 without issues). Lots of folks run, for example, web browsers off USB memory sticks for years - I have an old 1GB drive that's several years old and I keep a copy of PortableChrome on it. All the transient data like the browser cache and history files are kept on the stick and I haven't run into any problems yet. Also note that the MLC NAND chips typically found in these devices are only rated for 10,000 P/E cycles instead of the 100,000 for SLC chips like the OneNAND.

I'm sure that someone can concoct some nightmare-scenario or torture test that will easily result in blowing past the P/E cycle limit on some blocks but realistically speaking, it would need to be a LOT of continuous activity to run into those limits. Overall, even with EXT4, the OneNAND chip is going to be far more durable than your average USB memory stick or memory card for your camera. Granted, the usage patterns aren't exactly the same but then again, OneNAND is good for an order of magnitude more P/E cycles vs. the MLC chips found in these solutions.
 
Last edited:
  • Like
Reactions: yehster

msponsler

Senior Member
Sep 1, 2010
103
24
Harrisburg, PA
Journaling is there in order to rebuild data in the event of a power loss mid write.
A journal will rebuild the last write operation, staving off data corruption.

But let me ask you this...do you routinely start copying files on your phone and pull the battery? Probably not. Which is why journaling isn't very important on phones. You just have to wait the extra 10 seconds for the phone to shut down.
 

kenvan19

Senior Member
Dec 7, 2010
3,562
540
Journaling is there in order to rebuild data in the event of a power loss mid write.
A journal will rebuild the last write operation, staving off data corruption.

But let me ask you this...do you routinely start copying files on your phone and pull the battery? Probably not. Which is why journaling isn't very important on phones. You just have to wait the extra 10 seconds for the phone to shut down.

Wonderful! Thank you for clearing that up!
 

art3mis-nyc

Senior Member
Apr 21, 2010
236
97
New Yawk
Samsung Galaxy Z Fold3
So question, since Ext4 is efficient for stuff like usb style flash etc, and "bad"(note the quotes cuz of the claims) for phone style flash, wouldnt it be beneficial if the kernel/initramfs supported it to multi-format? essentially a partial "lagfix" where /cache and /data get partitioned to a mount on the SD and the multi writes/reads and the kernel and /system lives on the onenand, while moving the datadb partition to rfs?
more or less a hybrid where you gain the advantages of each, potentially a performance boost and reduce the wear and tear so to speak?

** just thinking of it all would love an explanation if im wrong in my thinking of behaviors of it.
*** Also because CW 3.0.0.5 supports the ability to partition however you tell it, yopu could multi partition this way, also couldnt we technically mimic google and shift to yaffs pretty easy as well(same way we did with ext4)?
 
Last edited:

plapczyn

Retired Recognized Developer
So question, since Ext4 is efficient for stuff like usb style flash etc, and "bad"(note the quotes cuz of the claims) for phone style flash, wouldnt it be beneficial if the kernel/initramfs supported it to multi-format? essentially a partial "lagfix" where /cache and /data get partitioned to a mount on the SD and the multi writes/reads and the kernel and /system lives on the onenand, while moving the datadb partition to rfs?
more or less a hybrid where you gain the advantages of each, potentially a performance boost and reduce the wear and tear so to speak?

** just thinking of it all would love an explanation if im wrong in my thinking of behaviors of it.
*** Also because CW 3.0.0.5 supports the ability to partition however you tell it, yopu could multi partition this way, also couldnt we technically mimic google and shift to yaffs pretty easy as well(same way we did with ext4)?

Exactly. It shouldn't matter if the RO partitions (system, kernel, radio) are formatted as EXT4 because the whole concern regarding program/erase cycles is mute. We should use whatever gives the best performance. Also, if it is truely that big of a deal, we could always go to YAFFS the same way we did with EXT4. Since google announced EXT4 as the default FS for 2.3+, I doubt it really was 'necessary' for YAFFS on the NAND. It is possible...that they chose to use a different low level device driver (faster?) and do the wear leveling in the FS layer.
 
Last edited:

lviv73

Senior Member
Mar 3, 2010
1,529
91
Buffalo NY
While still on the subject,how come none of these devs use RaiserFS in their roms?Raiserfs suposed to be real fast with small files.There are few Evo/Nexus roms/kernels with Raiserfs implemented and users report big speed boost over Ext4.
 

kenvan19

Senior Member
Dec 7, 2010
3,562
540
While still on the subject,how come none of these devs use RaiserFS in their roms?Raiserfs suposed to be real fast with small files.There are few Evo/Nexus roms/kernels with Raiserfs implemented and users report big speed boost over Ext4.

There must be a reason devs have not ported this. Perhaps there are issues?
 

aal1

Senior Member
Mar 29, 2008
120
24
Katy TX
Look, Im pretty techie myself, been a server administrator/architecht for 25+ years....linux, vmware, windows, etc. So I'm not dumb lol. Just wanted to understand a bit more....please bear with me on this....but can someone line-item out what benefit ext4 is going to give me on my epic running froyo?

maybe something like:

epic with dk28 (froyo) non-ext4 : blah blah


epic with DK28 (froyo) on ext 4 : blah blah PLUS blah BLAH brrrb BLAH and its faster or whatever.
 

msponsler

Senior Member
Sep 1, 2010
103
24
Harrisburg, PA
ThoughYou could move to reiserfs. I used it for many yeas, and I greatly enjoyed it.
However...reiserfs is a dead project. Hans reiser is in jail for mudering his wife. Reiserfs isn't without its problems though. It works we'll with files under 4kb. But it still uses the "big kernel lock", which is not the way to go IMHO. And reiserfs does suffer from degredation over time.

As far as the benefits of ext4:
Extents replacing block mapping improves I/O performance. It uses h-trees in the meta-data to drastically improve file location time. Actually mathematical genius...
Mutiple block allocators improve I/O time.
Ext4 is multi-threaded...yaffs2, rfs, ext2/3 are not
Allocate on flush, meaning blocks arent written until the data is ready. You'll sacrifice cpu/memory for I/O through put, but it does improve performance while reducing fragmentation.

15 years as a Linux and Solaris admin and engineer here. Always nice to meet another SA / Engineer!
 

aal1

Senior Member
Mar 29, 2008
120
24
Katy TX
hmmm ext4 is multi-threaded how?

let me throw a bit of what i understand here into the equation and ask differently....vmfs3 (esx filesystem) is comparable to ext3 right ? seems like I can multi-thread like a maniac on that filesystem with umpteen vms right? so basically ext4 is just another filesystem, like fat16 and ntfs, etc , and so we are just seeing the benefits of something written for newer SSD hardware in ext4?

Not trying to be any more newbish lol decided to just research more and found this little article....

http://www.phoronix.com/scan.php?page=article&item=ext4_btrfs_nilfs2&num=7

change the last number in the link to review the whole 7 page article.

It looks to me that ext4 is an upgrade over ext3 and shouldnt be such a big worry - as you said, it seems to have less frag problems, can write faster, writes in a different manner in order to get better throughput.

rhel6 pushes ext4 as a default, with btfrs as an option - which the above link basically proves to me with their testing. In short, ext4 is ready for primetime and works well for linux systems. And the others might not be.

So if you want a little more out of your phone, go ext4. want to be safe, stay where you are.

Since most of us wont have this phone in even 1 more year, more performance is the reason we are here anyways lol...so ext4 here I come I guess )


and a big SUP! to a fellow SA ) thanks for the info, I appreciate it.
 
Last edited:

h2g2

Senior Member
Dec 31, 2010
73
14
hmmm ext4 is multi-threaded how?
EXT4 isn't multi-threading but it supports file-level locking. YAFFS only supports partition-level locking. That means that only a single thread can write to a YAFFS partition at any moment in time. So long as that thread has a lock open, all other write operations to that partition are blocked until the lock is released.
 
  • Like
Reactions: DiGi760

Top Liked Posts

  • There are no posts matching your filters.
  • 34
    Background:
    Ok, so I write flash drivers for a living, so I would consider myself somewhat knowledgeable regarding flash technology.

    The flash is erased in 128k blocks and written in smaller pages. Data, once written, cannot be changed until you erase, so the FS will write to another page and invalidate the current page. The 100k program/erase cycle count is on a per block basis. It is not being erased every time you write a file, so calm down, your phone isn't going to die. The 10 year data retention time that people are quoting has nothing to do with this. It is how long once programmed...and not changed...data is guaranteed to be valid for.

    The only thing that you need to remotely consider...and needs to actually be verified, is whether RFS actually writes to the file system more or less than EXT4, and how much more. The data wear leveling is done on a lower layer than the file system and Dameon87 already confirmed both RFS and EXT4 are using the same sector translation layer.

    Sources:
    XDA Post linking RFS documentation: http://forum.xda-developers.com/showthread.php?t=801223
    Reliability: http://www.samsung.com/global/busin...s/fusionmemory/Products_FAQs_Reliability.html
    Datasheet: http://www.datasheetcatalog.org/datasheets2/12/1248447_1.pdf
    Attached are app notes on RFS.

    Regarding RFS:
    RFS Programming Guide said:
    STL Block Device Driver: This block device driver is used to provide driver functions for the device files /dev/stl0/*, /dev/stl1/* and so on. Since there is FTL between this block device driver and BML, it is allowed to perform random write requests and write requests are handled atomically. Thus any read-write file system (e.g. RFS) can run on this block device driver.

    STL (Sector Translation Layer): translates a logical address from the file system into the virtual flash address. It internally has wear-leveling during the address translation.

    Regarding EXT4:
    EXT4 supposedly buffers more data before writing, thus in theory should require less program/erase cycles. This could in theory explain why people claim better battery life using EXT4. To program/erase flash, you must temporarily raise the flash voltage...this is why flashing ROMs and using ODIN drain your battery like crazy...and why you should always flash with a battery near 100%. This point is of course mute if there is no wear protection. If EXT4 is using the Samsung STL driver, the wear leveling should be implemented exactly the same as in RFS.

    Regarding Bad Blocks:
    It is typical to have some bad blocks in large flash arrays direct from the factory. It is normal and part of the manufacturing/validation process.
    http://www.samsung.com/global/business/semiconductor/products/fusionmemory/Products_FAQs_Reliability.html said:
    SAMSUNG guarantees the first block will operate properly during the 100K P/E cycle under normal conditions. On the other hand, other blocks can be invalid as long as the total number of bad blocks doesn't exceed 2% of all blocks.

    Samsung Datasheet said:
    The device may include invalid blocks when first shipped. Additional invalid blocks may develop while being used. The number of valid blocks is presented
    with both cases of invalid blocks considered. Invalid blocks are defined as blocks that contain one or more bad bits. Do not erase or program factory-marked bad blocks.

    Invalid blocks are defined as blocks that contain one or more invalid bits whose reliability is not guaranteed by Samsung. The information
    regarding the invalid block(s) is so called as the invalid block information. Devices with invalid block(s) have the same quality
    level as devices with all valid blocks and have the same AC and DC characteristics. An invalid block(s) does not affect the performance
    of valid block(s) because it is isolated from the bit line and the common source line by a select transistor.
    The system design
    must be able to mask out the invalid block(s) via address mapping. The 1st block, which is placed on 00h block address, is fully guaranteed
    to be a valid block.

    Within its life time, additional invalid blocks may develop with the device. Refer to the qualification report for the actual data.The following
    possible failure modes should be considered to implement a highly reliable system. In the case of status read failure after
    erase or program, block replacement should be done. Because program status fail during a page program does not affect the data of
    the other pages in the same block, block replacement can be executed with a page-sized buffer by finding an erased empty block and
    reprogramming the current target data and copying the rest of the replaced block.

    Check your bad datablocks by doing this...
    Code:
    adb shell
    su
    cat /proc/L*/bmlinfo

    You will probably have a few. I have 3. The block size is 128KB. 512MB/128KB = 4096 blocks (thats why they are using the bottom blocks in the 4000 range for the 2% coverage. 2% of 4096 is apx 81 bad blocks. But don't worry. You would have to get about 3 bad blocks per month for 2 years straight before a failure.

    Conclusion:
    Now of course the best way to extend the life of the flash is to use the SD card for partitions that get continually written to like /data...and don't flash new roms 100 times a day for 2 years. But you really don't have to worry about the dreaded flash fairy coming and breaking your phone after a week. Since FAT writes to the fixed location file allocation table over and over, Samsung already has the wear leveling in place. Moreover, RFS adds journaling and posix commands to FAT and was mounted with atime. Most likely, it was doing MORE file IO than EXT4. Below is a link to some info on EXT4 disk writes. Clearly using noatime and journaling off is the best option for flash with regard to longevity, however, the difference isn't as big as you would think.

    Further Reading:
    The Truth About RFS (warning lacks citation): http://forum.xda-developers.com/showthread.php?t=799931
    EXT4 Performance testing: http://thunk.org/tytso/blog/2009/03/01/ssds-journaling-and-noatimerelatime/
    2
    So in your opinion even if Ext4 degregades nand lets say 2-3 times faster than RFS,would Epic still function normaly with heavy daily use for 2-3 years?

    Code:
    EXT4_lifecycle = RFS_flash_lifecycle * (EXT4_write_cycles/RFS_write_cycles)
    2
    Updated post to add info on bad blocks and more links to references.
    1
    Moved to general section for discussion.

    Again, no flamming...

    Yeah, I should have put it in general. I wasn't trying to flame, but generally speaking, quoting ones self doesn't count as a valid citation.
    1
    I believe Quadrant Advanced gives you a numerical breakdown on I/O reads and writes. I know "it feels faster" isn't what you're looking for but when running EXT4 you can really tell the difference. I have been running EXT4 with journaling for months and I find it rough to run RFS..at least on the Epic. I will have to see about my other phone tomorrow. I believe SQ Lite RL benchmark will give you some numbers as well
    Sent from my SPH-D700 using xda premium