Hi guys
also a good card
looks like same manfid and controller like the first filemate card in your list
*********************************************** **** Lexar mobile microSDHC class 6, 16 GB **** *********************************************** ==> /sys/block/mmcblk0/device/cid <== 2842454c455841521029101ade00ac00
==> /sys/block/mmcblk0/device/csd <== 400e00325b590000774d7f800a400000
==> /sys/block/mmcblk0/device/scr <== 0235800000000000
==> /sys/block/mmcblk0/device/fwrev <== 0x0
==> /sys/block/mmcblk0/device/hwrev <== 0x1
==> /sys/block/mmcblk0/device/cid <== 2842454c455841521029101ade00ac00
==> /sys/block/mmcblk0/device/manfid <== 0x000028
==> /sys/block/mmcblk0/device/oemid <== 0x4245
==> /sys/block/mmcblk0/device/serial <== 0x29101ade
==> /sys/block/mmcblk0/device/erase_size <== 512
==> /sys/block/mmcblk0/device/preferred_erase_size <== 4194304
==> /sys/block/mmcblk0/device/name <== LEXAR
==> /sys/block/mmcblk0/device/date <== 12/2010 clock: 33000000 Hz vdd: 20 (3.2 ~ 3.3 V) bus mode: 2 (push-pull) chip select: 0 (don't care) power mode: 2 (on) bus width: 2 (4 bits) timing spec: 2 (sd high-speed)
$ fdisk -lu /dev/sda
Disk /dev/sda: 16.0 GB, 16012804096 bytes 128 heads, 32 sectors/track, 7635 cylinders, total 31275008 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0x00000000
Device Boot Start End Blocks Id System /dev/sda1 1 614399 307199+ 83 Linux /dev/sda2 614400 819199 102400 83 Linux /dev/sda3 819200 1851391 516096 82 Linux swap / Solaris /dev/sda4 1851392 7364607 2756608 83 Linux
$ ./flashbench -a /dev/sda3 --count=100 --blocksize=2048 align 134217728 pre 722µs on 853µs post 722µs diff 131µs align 67108864 pre 724µs on 857µs post 724µs diff 133µs align 33554432 pre 726µs on 853µs post 724µs diff 128µs align 16777216 pre 724µs on 853µs post 721µs diff 131µs align 8388608 pre 721µs on 845µs post 717µs diff 126µs align 4194304 pre 722µs on 726µs post 722µs diff 3.42µs align 2097152 pre 726µs on 726µs post 724µs diff 1.07µs align 1048576 pre 725µs on 728µs post 728µs diff 2.17µs align 524288 pre 729µs on 729µs post 729µs diff -275ns align 262144 pre 727µs on 728µs post 727µs diff 541ns align 131072 pre 723µs on 725µs post 727µs diff 542ns align 65536 pre 722µs on 720µs post 721µs diff -1576ns align 32768 pre 728µs on 726µs post 727µs diff -1480ns align 16384 pre 719µs on 721µs post 713µs diff 5.35µs align 8192 pre 724µs on 730µs post 729µs diff 3.25µs align 4096 pre 727µs on 727µs post 731µs diff -1882ns
-> 8MiB erase-block size
$ ./flashbench --open-au --open-au-nr=1 --erasesize=$[16*1024*1024] --blocksize=$[1024*1024] /dev/sda3 16MiB 8.99M/s 8MiB 14.5M/s 4MiB 15M/s 2MiB 15.1M/s 1MiB 16M/s
-> ok, definitively 8MiB erase-block size
$ ./flashbench --open-au --open-au-nr=1 --erasesize=$[8*1024*1024] --blocksize=2048 /dev/sda3 8MiB 14.6M/s 4MiB 14.6M/s 2MiB 14.8M/s 1MiB 15.7M/s 512KiB 15M/s 256KiB 15.4M/s 128KiB 14.6M/s 64KiB 15.7M/s 32KiB 10.5M/s 16KiB 7.05M/s 8KiB 4.25M/s 4KiB 2.42M/s 2KiB 1.38M/s
$ ./flashbench --open-au --open-au-nr=3 --erasesize=$[8*1024*1024] --blocksize=2048 /dev/sda3 8MiB 14.7M/s 4MiB 10.2M/s 2MiB 14.8M/s 1MiB 15.6M/s 512KiB 15.4M/s 256KiB 15.4M/s 128KiB 14.7M/s 64KiB 13.5M/s 32KiB 10.6M/s 16KiB 7.16M/s 8KiB 4.31M/s 4KiB 2.22M/s 2KiB 1.12M/s
$ ./flashbench --open-au --open-au-nr=5 --erasesize=$[8*1024*1024] --blocksize=2048 /dev/sda3 8MiB 14.7M/s 4MiB 9.31M/s 2MiB 14.9M/s 1MiB 15.5M/s 512KiB 15.7M/s 256KiB 15.1M/s 128KiB 14.7M/s 64KiB 13.6M/s 32KiB 10.7M/s 16KiB 7.17M/s 8KiB 4.34M/s 4KiB 2.21M/s 2KiB 1.14M/s
$ ./flashbench --open-au --open-au-nr=6 --erasesize=$[8*1024*1024] --blocksize=$[1024*1024] /dev/sda3 8MiB 14.8M/s 4MiB 4.07M/s 2MiB 2.34M/s 1MiB 1.28M/s
-> can handle 5 blocks concurrently
$ ./flashbench --open-au --open-au-nr=10 --erasesize=$[8*1024*1024] --blocksize=2048 /dev/sda3 8MiB 14.8M/s 4MiB 4.91M/s 2MiB 2.33M/s 1MiB 1.28M/s 512KiB 671K/s ^C
$ ./flashbench --open-au --open-au-nr=20 --erasesize=$[8*1024*1024] /dev/sda3 8MiB 13.7M/s 4MiB 4.11M/s ^C
$ ./flashbench --open-au --open-au-nr=40 --erasesize=$[8*1024*1024] /dev/sda3 8MiB 14.3M/s 4MiB 4M/s ^C
$ ./flashbench --open-au --open-au-nr=100 --erasesize=$[8*1024*1024] /dev/sda3 8MiB 13.6M/s ^C
$ ./flashbench --open-au --open-au-nr=300 --erasesize=$[8*1024*1024] /dev/sda3 8MiB 14.7M/s ^C
-> is this some sort of caching?
$ ./flashbench --open-au --open-au-nr=5 --erasesize=$[8*1024*1024] --blocksize=2048 /dev/sda3 --random 8MiB 13.3M/s 4MiB 13.3M/s 2MiB 13.4M/s 1MiB 13.7M/s 512KiB 12.6M/s 256KiB 11.9M/s 128KiB 10.6M/s 64KiB 11.3M/s 32KiB 8.21M/s 16KiB 5.16M/s 8KiB 2.92M/s 4KiB 1.2M/s 2KiB 588K/s
-> still good
$ ./flashbench --open-au --open-au-nr=5 --erasesize=$[8*1024*1024] --blocksize=2048 /dev/sda3 --random --offset=$[4*1024*1024] 8MiB 2.93M/s 4MiB 4.35M/s 2MiB 2.35M/s 1MiB 1.67M/s 512KiB 1.05M/s 256KiB 656K/s 128KiB 340K/s 64KiB 168K/s ^C
-> unaligned: crap
peter
On Wednesday 13 July 2011, Peter Warasin wrote:
Hi guys
also a good card
looks like same manfid and controller like the first filemate card in your list
Ah, I wondered about this. I also had a Sandisk-labelled card with the same controller and name "LEXAR", so this is probably the same hardware. Sandisk also confirmed to me that the card I had was not an authentic Sandisk card.
==> /sys/block/mmcblk0/device/oemid <== 0x4245
"BE", same as the other 0x0028 manfid cards
$ ./flashbench -a /dev/sda3 --count=100 --blocksize=2048 align 134217728 pre 722µs on 853µs post 722µs diff 131µs align 67108864 pre 724µs on 857µs post 724µs diff 133µs align 33554432 pre 726µs on 853µs post 724µs diff 128µs align 16777216 pre 724µs on 853µs post 721µs diff 131µs align 8388608 pre 721µs on 845µs post 717µs diff 126µs align 4194304 pre 722µs on 726µs post 722µs diff 3.42µs align 2097152 pre 726µs on 726µs post 724µs diff 1.07µs align 1048576 pre 725µs on 728µs post 728µs diff 2.17µs align 524288 pre 729µs on 729µs post 729µs diff -275ns align 262144 pre 727µs on 728µs post 727µs diff 541ns align 131072 pre 723µs on 725µs post 727µs diff 542ns align 65536 pre 722µs on 720µs post 721µs diff -1576ns align 32768 pre 728µs on 726µs post 727µs diff -1480ns align 16384 pre 719µs on 721µs post 713µs diff 5.35µs align 8192 pre 724µs on 730µs post 729µs diff 3.25µs align 4096 pre 727µs on 727µs post 731µs diff -1882ns
-> 8MiB erase-block size
Yes, this is a strong indication.
$ ./flashbench --open-au --open-au-nr=1 --erasesize=$[16*1024*1024] --blocksize=$[1024*1024] /dev/sda3 16MiB 8.99M/s 8MiB 14.5M/s 4MiB 15M/s 2MiB 15.1M/s 1MiB 16M/s
-> ok, definitively 8MiB erase-block size
This is not a strong indication, all you can see from this is that the first write was slower, but that can be because it did a garbage-collection before.
$ ./flashbench --open-au --open-au-nr=5 --erasesize=$[8*1024*1024] --blocksize=2048 /dev/sda3 8MiB 14.7M/s 4MiB 9.31M/s 2MiB 14.9M/s 1MiB 15.5M/s 512KiB 15.7M/s 256KiB 15.1M/s 128KiB 14.7M/s 64KiB 13.6M/s 32KiB 10.7M/s 16KiB 7.17M/s 8KiB 4.34M/s 4KiB 2.21M/s 2KiB 1.14M/s
$ ./flashbench --open-au --open-au-nr=6 --erasesize=$[8*1024*1024] --blocksize=$[1024*1024] /dev/sda3 8MiB 14.8M/s 4MiB 4.07M/s 2MiB 2.34M/s 1MiB 1.28M/s
-> can handle 5 blocks concurrently
Yes.
$ ./flashbench --open-au --open-au-nr=10 --erasesize=$[8*1024*1024] --blocksize=2048 /dev/sda3 8MiB 14.8M/s 4MiB 4.91M/s 2MiB 2.33M/s 1MiB 1.28M/s 512KiB 671K/s ^C
$ ./flashbench --open-au --open-au-nr=20 --erasesize=$[8*1024*1024] /dev/sda3 8MiB 13.7M/s 4MiB 4.11M/s ^C
$ ./flashbench --open-au --open-au-nr=40 --erasesize=$[8*1024*1024] /dev/sda3 8MiB 14.3M/s 4MiB 4M/s ^C
$ ./flashbench --open-au --open-au-nr=100 --erasesize=$[8*1024*1024] /dev/sda3 8MiB 13.6M/s ^C
$ ./flashbench --open-au --open-au-nr=300 --erasesize=$[8*1024*1024] /dev/sda3 8MiB 14.7M/s ^C
-> is this some sort of caching?
No. What happens is that every write access is a whole erase block, so the card never has to do any garbage-collection. In the last run, flashbench will pick 300 8MB erase blocks (every 6th with the latest version), and write full 8 MB to each, overwriting whatever was there before.
The second row of each test, flashbench writes the first 4MB of each 8MB block, then writes the other 4 MB. If you do this for more than 5 erase blocks on this card, it will garbage-collect the first block by copying the remaining 4 MB in order to 'close' that erase block and start writing to the sixth one. So instead of 'write 4MB; write 4MB', the card does 'write 4MB; read 4MB; write 4MB; write 4MB; read 4 MB; write 4MB', which roughly triples the time to write a total of 8 MB for the case where it writes more than 5 segments compared to up to 5 segments.
This gets much worse for smaller blocks, where 2048*(write 4KB) turns into 2048*(write 4KB; read 8188 KB; write 8188KB).
See https://lwn.net/Articles/428799/ "SSD thrashing".
Arnd
hi
On 13/07/11 15:23, Arnd Bergmann wrote:
looks like same manfid and controller like the first filemate card in your list
Ah, I wondered about this. I also had a Sandisk-labelled card with the same controller and name "LEXAR", so this is probably the same hardware. Sandisk also confirmed to me that the card I had was not an authentic Sandisk card.
interesting. so this is probably a fake? but the same 8GB card has similar values but a different manfid and oemid..
-> ok, definitively 8MiB erase-block size
This is not a strong indication, all you can see from this is that the first write was slower, but that can be because it did a garbage-collection before.
ok, i see
No. What happens is that every write access is a whole erase block,
[..]
so this should be always the case then, that writing with the exact erase-block size remains fast also with many concurrent blocks
See https://lwn.net/Articles/428799/ "SSD thrashing".
great, thank's
peter
On Wednesday 13 July 2011, Peter Warasin wrote:
hi
On 13/07/11 15:23, Arnd Bergmann wrote:
looks like same manfid and controller like the first filemate card in your list
Ah, I wondered about this. I also had a Sandisk-labelled card with the same controller and name "LEXAR", so this is probably the same hardware. Sandisk also confirmed to me that the card I had was not an authentic Sandisk card.
interesting. so this is probably a fake? but the same 8GB card has similar values but a different manfid and oemid..
I wouldn't say 'probably', but it's at least noteworthy that you have cards with two different manufacturer id fields from a company that claims to make everything themselves. If one of the two is fake, it's at least not clear which one is.
No. What happens is that every write access is a whole erase block,
[..]
so this should be always the case then, that writing with the exact erase-block size remains fast also with many concurrent blocks
Yes, exactly. Another way to find out the erase block size based on this is to use
for i in 1 2 3 4 6 8 ; do echo Size $[$i * 1024 * 1024] flashbench --erasesize=$[$i * 1024 * 1024] --blocksize=$[$i * 1024 * 1024] --open-au --open-au-nr=10 echo Size $[$i * 1024 * 1024], align $[$i/2 * 1024 * 1024] flashbench --erasesize=$[$i * 1024 * 1024] --blocksize=$[$i * 1024 * 1024] --open-au --open-au-nr=10 --align=$[$i/2 * 1024 * 1024] done
Any naturally aligned erase blocks or multiples of it should be fine here, while unaligned blocks and smaller blocks are not.
Arnd
On Wednesday 13 July 2011, Arnd Bergmann wrote:
interesting. so this is probably a fake? but the same 8GB card has similar values but a different manfid and oemid..
I wouldn't say 'probably', but it's at least noteworthy that you have cards with two different manufacturer id fields from a company that claims to make everything themselves. If one of the two is fake, it's at least not clear which one is.
To follow up on this, the two tests you posted from the Lexar 8 GB cards (class 4 and 6) show almost identical results, which is highly unusual.
There are only two reasonable explanations for this:
* They are in fact identical controllers and flash chips, but one of them has been flashed to report a different manufacturer ID. This still doesn't guarantee that they are both authentic (e.g. one could be a graveyard shift run from scrap chips), but it's a good hint
* You accidentally measured the same card twice and one of the two test runs you posted does not match the card. Can you look again to be sure that the results are matching up? In particular, the size is normally different for every new controller.
Arnd
hi
On 14/07/11 14:06, Arnd Bergmann wrote:
To follow up on this, the two tests you posted from the Lexar 8 GB cards (class 4 and 6) show almost identical results, which is highly unusual.
really those 2 cards? or do you mean class 6 8Gb and 16Gb? because on higher nr of blocks numbers vary much on these 2. class6 is imho way better than class4.
- You accidentally measured the same card twice and one of the two test runs you posted does not match the card. Can you look again to be sure that the results are matching up? In particular, the size is normally different for every new controller.
the number of sector are really the same on both cards. re-did a test with class4 card and those numbers are correct. the class6 card was the best so far, we do product tests with it, so i can't redo the tests, only thing i can tell now is that fdisk tells the same size
peter
On Monday 18 July 2011, Peter Warasin wrote:
On 14/07/11 14:06, Arnd Bergmann wrote:
To follow up on this, the two tests you posted from the Lexar 8 GB cards (class 4 and 6) show almost identical results, which is highly unusual.
really those 2 cards? or do you mean class 6 8Gb and 16Gb? because on higher nr of blocks numbers vary much on these 2. class6 is imho way better than class4.
The 16GB class 6 has the same manfid as the 8GB class 4, I expect them to be quite similar.
For the class4 card, you have listed
$ ./flashbench /dev/sda3 --open-au-nr=5 -O --blocksize=2048 --random 4MiB 10.7M/s 2MiB 10.5M/s 1MiB 10.5M/s 512KiB 10.2M/s 256KiB 9.75M/s 128KiB 9.67M/s 64KiB 9.54M/s 32KiB 7.59M/s 16KiB 5.5M/s 8KiB 3.19M/s 4KiB 1.25M/s 2KiB 613K/s
and for the class 6 card
./flashbench /dev/sda3 --open-au-nr=5 -O --blocksize=2048 --random 4MiB 10.2M/s 2MiB 9.95M/s 1MiB 10.1M/s 512KiB 9.89M/s 256KiB 9.7M/s 128KiB 9.3M/s 64KiB 9.07M/s 32KiB 7.31M/s 16KiB 5.21M/s 8KiB 3.02M/s 4KiB 1.2M/s 2KiB 584K/s
The numbers are all very close. If anything, the class 4 performs slightly better except that it hangs at some point, but that might not be an unrelated problem.
- You accidentally measured the same card twice and one of the two test runs you posted does not match the card. Can you look again to be sure that the results are matching up? In particular, the size is normally different for every new controller.
the number of sector are really the same on both cards. re-did a test with class4 card and those numbers are correct. the class6 card was the best so far, we do product tests with it, so i can't redo the tests, only thing i can tell now is that fdisk tells the same size
ok.
Arnd
flashbench-results@lists.linaro.org
-
Arnd Bergmann -
Peter Warasin