hi guys
tests for a kingston 2GB micro SD card
BTW: must these tests been done on a partition which is 4MiB aligned?
$ cat /sys/kernel/debug/mmc0/ios clock: 50000000 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)
$ head /sys/block/mmcblk0/device/{c*,scr,*rev,*id,serial,*size*,name,date} ==> /sys/block/mmcblk0/device/cid <== 02544d5341303247052087b4c800a800
==> /sys/block/mmcblk0/device/csd <== 002e00325b5aa3acffffff800a800000
==> /sys/block/mmcblk0/device/scr <== 0225800001000000
==> /sys/block/mmcblk0/device/fwrev <== 0x5
==> /sys/block/mmcblk0/device/hwrev <== 0x0
==> /sys/block/mmcblk0/device/cid <== 02544d5341303247052087b4c800a800
==> /sys/block/mmcblk0/device/manfid <== 0x000002
==> /sys/block/mmcblk0/device/oemid <== 0x544d
==> /sys/block/mmcblk0/device/serial <== 0x2087b4c8 head: cannot open `/sys/block/mmcblk0/device/*size*' for reading: No such file or directory
==> /sys/block/mmcblk0/device/name <== SA02G
==> /sys/block/mmcblk0/device/date <== 08/2010
$ sfdisk -s /dev/mmcblk0 1927168
./flashbench -a --blocksize=1024 /dev/mmcblk0p3 align 134217728 pre 1.69ms on 1.86ms post 1.29ms diff 375µs align 67108864 pre 1.87ms on 2.04ms post 1.35ms diff 432µs align 33554432 pre 1.91ms on 2.08ms post 1.35ms diff 455µs align 16777216 pre 1.83ms on 2ms post 1.32ms diff 426µs align 8388608 pre 1.83ms on 2ms post 1.32ms diff 426µs align 4194304 pre 1.77ms on 1.97ms post 1.29ms diff 441µs align 2097152 pre 1.8ms on 1.97ms post 1.29ms diff 425µs align 1048576 pre 1.51ms on 1.98ms post 1.29ms diff 579µs align 524288 pre 1.27ms on 1.45ms post 1.29ms diff 169µs align 262144 pre 1.27ms on 1.45ms post 1.29ms diff 169µs align 131072 pre 1.27ms on 1.45ms post 1.29ms diff 169µs align 65536 pre 1.26ms on 1.44ms post 1.29ms diff 164µs align 32768 pre 1.27ms on 1.45ms post 1.29ms diff 169µs align 16384 pre 1.29ms on 1.45ms post 1.27ms diff 168µs align 8192 pre 1.29ms on 1.46ms post 1.29ms diff 177µs align 4096 pre 1.29ms on 1.33ms post 1.29ms diff 40µs align 2048 pre 1.29ms on 1.33ms post 1.29ms diff 39.4µs
i assume i see the erase-block size where pre value is smallest (??) erase-block size 64Kib? that can't possible be, can it?
$ ./flashbench --open-au --open-au-nr=1 /dev/mmcblk0p3 4MiB 5.94M/s 2MiB 4.21M/s 1MiB 4.26M/s 512KiB 3.27M/s 256KiB 4.27M/s 128KiB 5.91M/s 64KiB 10.3M/s 32KiB 8.76M/s 16KiB 7.06M/s
$ ./flashbench --open-au --open-au-nr=2 /dev/mmcblk0p3 4MiB 9.87M/s 2MiB 10.1M/s 1MiB 4.54M/s 512KiB 1.97M/s 256KiB 945K/s 128KiB 464K/s 64KiB 213K/s 32KiB 112K/s 16KiB 55.4K/s
$ ./flashbench --open-au --open-au-nr=3 /dev/mmcblk0p3 4MiB 8.18M/s 2MiB 9.97M/s 1MiB 4.42M/s 512KiB 1.96M/s 256KiB 942K/s 128KiB 463K/s 64KiB 218K/s 32KiB 111K/s 16KiB 55.5K/s
means the card can handle only 1 block at once, does it? because performance is constant only with 1 block and 4MiB erase-block should be fine (?)
./flashbench --open-au --open-au-nr=1 /dev/mmcblk0p3 --erasesize=$[1 * 1024 * 1024] 1MiB 2.72M/s 512KiB 1.97M/s 256KiB 1.98M/s 128KiB 1.97M/s 64KiB 4.25M/s 32KiB 4.03M/s 16KiB 3.6M/s
$./flashbench --open-au --open-au-nr=1 /dev/mmcblk0p3 --erasesize=$[2 * 1024 * 1024] 2MiB 9.97M/s 1MiB 2.26M/s 512KiB 1.97M/s 256KiB 2.71M/s 128KiB 4.23M/s 64KiB 1.78M/s 32KiB 5.19M/s 16KiB 7.08M/s
./flashbench --open-au --open-au-nr=1 /dev/mmcblk0p3 --erasesize=$[4 * 1024 * 1024] 4MiB 6.03M/s 2MiB 4.27M/s 1MiB 3.26M/s 512KiB 3.32M/s 256KiB 3.33M/s 128KiB 6M/s 64KiB 10.3M/s 32KiB 8.96M/s 16KiB 7.05M/s
so, 2MiB is better, is it? hmm, does that turbo-boost at 64KiB mean that's the correct page size?
tests with --random:
$ ./flashbench --open-au --open-au-nr=1 /dev/mmcblk0p3 --erasesize=$[2 * 1024 * 1024] --random 2MiB 4.27M/s 1MiB 1.76M/s 512KiB 998K/s 256KiB 633K/s 128KiB 419K/s 64KiB 325K/s 32KiB 177K/s 16KiB 86.1K/s
$ ./flashbench --open-au --open-au-nr=1 /dev/mmcblk0p3 --erasesize=$[4 * 1024 * 1024] --random 4MiB 5.99M/s 2MiB 2.01M/s 1MiB 2.92M/s 512KiB 1.2M/s 256KiB 605K/s 128KiB 318K/s 64KiB 241K/s 32KiB 129K/s 16KiB 65.2K/s
./flashbench --open-au --open-au-nr=1 /dev/mmcblk0p3 --erasesize=$[1 * 1024 * 1024] --random 1MiB 2.75M/s 512KiB 804K/s 256KiB 984K/s 128KiB 377K/s 64KiB 265K/s 32KiB 186K/s 16KiB 78.8K/s
./flashbench --open-au-nr=1 --random /dev/mmcblk0p3 -O --erasesize=$[1536 * 1024] --blocksize=$[96 * 1024] 1.5MiB 3.57M/s 768KiB 1.02M/s 384KiB 1.53M/s 192KiB 546K/s 96KiB 311K/s
./flashbench --open-au-nr=1 --random /dev/mmcblk0p3 -O --erasesize=$[3072 * 1024] --blocksize=$[96 * 1024] 3MiB 5.34M/s 1.5MiB 2.29M/s 768KiB 2.1M/s 384KiB 888K/s 192KiB 470K/s 96KiB 233K/s
./flashbench --open-au-nr=1 --random /dev/mmcblk0p3 -O --erasesize=$[6144 * 1024] --blocksize=$[96 * 1024] 6MiB 6.97M/s 3MiB 2.9M/s 1.5MiB 2.61M/s 768KiB 1.49M/s 384KiB 881K/s 192KiB 442K/s 96KiB 216K/s
./flashbench --open-au-nr=1 --random /dev/mmcblk0p3 -O --erasesize=$[8192 * 1024] --blocksize=$[64 * 1024] 8MiB 7.63M/s 4MiB 3.33M/s 2MiB 3.71M/s 1MiB 2.58M/s 512KiB 1.19M/s 256KiB 604K/s 128KiB 282K/s 64KiB 242K/s
hope these numbers help somehow.. i'm lost in numbers now :)
peter
On Monday 11 July 2011 18:16:50 Peter Warasin wrote:
hi guys
tests for a kingston 2GB micro SD card
BTW: must these tests been done on a partition which is 4MiB aligned?
Yes, the partition must be aligned to the erase block size, in this case probably 1MB. You can add something like '--offset=$[123 * 512]' to move the start of the test run 123 sectors into the drive to correct this.
If the partition is misaligned, that will improve the measurement, but the numbers here indicate that the alignment is indeed at least 1MB.
./flashbench -a --blocksize=1024 /dev/mmcblk0p3 align 134217728 pre 1.69ms on 1.86ms post 1.29ms diff 375µs align 67108864 pre 1.87ms on 2.04ms post 1.35ms diff 432µs align 33554432 pre 1.91ms on 2.08ms post 1.35ms diff 455µs align 16777216 pre 1.83ms on 2ms post 1.32ms diff 426µs align 8388608 pre 1.83ms on 2ms post 1.32ms diff 426µs align 4194304 pre 1.77ms on 1.97ms post 1.29ms diff 441µs align 2097152 pre 1.8ms on 1.97ms post 1.29ms diff 425µs align 1048576 pre 1.51ms on 1.98ms post 1.29ms diff 579µs align 524288 pre 1.27ms on 1.45ms post 1.29ms diff 169µs align 262144 pre 1.27ms on 1.45ms post 1.29ms diff 169µs align 131072 pre 1.27ms on 1.45ms post 1.29ms diff 169µs align 65536 pre 1.26ms on 1.44ms post 1.29ms diff 164µs align 32768 pre 1.27ms on 1.45ms post 1.29ms diff 169µs align 16384 pre 1.29ms on 1.45ms post 1.27ms diff 168µs align 8192 pre 1.29ms on 1.46ms post 1.29ms diff 177µs align 4096 pre 1.29ms on 1.33ms post 1.29ms diff 40µs align 2048 pre 1.29ms on 1.33ms post 1.29ms diff 39.4µs
i assume i see the erase-block size where pre value is smallest (??) erase-block size 64Kib? that can't possible be, can it?
The erase block size is usually the point where the last column has the largest drop, in this case between 1MB and 512KB, so the erase block is 1MB.
The page size is probably 8KB according to this, i.e. the other drop.
What the number show is:
* It takes around 1.29ms to read 1KB within a page * It takes around 1.46ms to read 1KB across a page boundary * It takes around 1.97ms to read 1KB across an erase block
Quite typical for a 2GB card or smaller.
$ ./flashbench --open-au --open-au-nr=1 /dev/mmcblk0p3 4MiB 5.94M/s 2MiB 4.21M/s 1MiB 4.26M/s 512KiB 3.27M/s 256KiB 4.27M/s 128KiB 5.91M/s 64KiB 10.3M/s 32KiB 8.76M/s 16KiB 7.06M/s
$ ./flashbench --open-au --open-au-nr=2 /dev/mmcblk0p3 4MiB 9.87M/s 2MiB 10.1M/s 1MiB 4.54M/s 512KiB 1.97M/s 256KiB 945K/s 128KiB 464K/s 64KiB 213K/s 32KiB 112K/s 16KiB 55.4K/s
$ ./flashbench --open-au --open-au-nr=3 /dev/mmcblk0p3 4MiB 8.18M/s 2MiB 9.97M/s 1MiB 4.42M/s 512KiB 1.96M/s 256KiB 942K/s 128KiB 463K/s 64KiB 218K/s 32KiB 111K/s 16KiB 55.5K/s
means the card can handle only 1 block at once, does it? because performance is constant only with 1 block and 4MiB erase-block should be fine (?)
Yes, this is the main problem with Kingston cards. You can see the effect all over the table in https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey for every Kingston SD card.
./flashbench --open-au --open-au-nr=1 /dev/mmcblk0p3 --erasesize=$[1 * 1024 * 1024] 1MiB 2.72M/s 512KiB 1.97M/s 256KiB 1.98M/s 128KiB 1.97M/s 64KiB 4.25M/s 32KiB 4.03M/s 16KiB 3.6M/s
$./flashbench --open-au --open-au-nr=1 /dev/mmcblk0p3 --erasesize=$[2 * 1024 * 1024] 2MiB 9.97M/s 1MiB 2.26M/s 512KiB 1.97M/s 256KiB 2.71M/s 128KiB 4.23M/s 64KiB 1.78M/s 32KiB 5.19M/s 16KiB 7.08M/s
./flashbench --open-au --open-au-nr=1 /dev/mmcblk0p3 --erasesize=$[4 * 1024 * 1024] 4MiB 6.03M/s 2MiB 4.27M/s 1MiB 3.26M/s 512KiB 3.32M/s 256KiB 3.33M/s 128KiB 6M/s 64KiB 10.3M/s 32KiB 8.96M/s 16KiB 7.05M/s
so, 2MiB is better, is it?
I think this has more to do with the alignment of the first erase block. If the partition start is not aligned to a full multiple of the erase block size, larger blocks are simply faster because you actually end up writing full erase blocks, while writing 1MB across two partial erase blocks is rather slow.
hmm, does that turbo-boost at 64KiB mean that's the correct page size?
No, you can see this effect for very many media from different vendors. I have two possible explanations for this:
1. The cards optimize for the behaviour of microsoft windows, which is known to normally write exactly 64KB at once. 2. It's an artifact of the way that the Linux block layer works.
Possibly it's also a combination of these two.
tests with --random:
$ ./flashbench --open-au --open-au-nr=1 /dev/mmcblk0p3 --erasesize=$[2
- 1024 * 1024] --random
2MiB 4.27M/s 1MiB 1.76M/s 512KiB 998K/s 256KiB 633K/s 128KiB 419K/s 64KiB 325K/s 32KiB 177K/s 16KiB 86.1K/s
$ ./flashbench --open-au --open-au-nr=1 /dev/mmcblk0p3 --erasesize=$[4
- 1024 * 1024] --random
4MiB 5.99M/s 2MiB 2.01M/s 1MiB 2.92M/s 512KiB 1.2M/s 256KiB 605K/s 128KiB 318K/s 64KiB 241K/s 32KiB 129K/s 16KiB 65.2K/s
./flashbench --open-au --open-au-nr=1 /dev/mmcblk0p3 --erasesize=$[1 * 1024 * 1024] --random 1MiB 2.75M/s 512KiB 804K/s 256KiB 984K/s 128KiB 377K/s 64KiB 265K/s 32KiB 186K/s 16KiB 78.8K/s
This mainly shows how Kingston cards suck with random I/O: You cannot even write a single erase block efficiently doing random writes with an erase block. When you have this behaviour, doing more --random tests does not help you any further.
./flashbench --open-au-nr=1 --random /dev/mmcblk0p3 -O --erasesize=$[1536 * 1024] --blocksize=$[96 * 1024] 1.5MiB 3.57M/s 768KiB 1.02M/s 384KiB 1.53M/s 192KiB 546K/s 96KiB 311K/s
./flashbench --open-au-nr=1 --random /dev/mmcblk0p3 -O --erasesize=$[3072 * 1024] --blocksize=$[96 * 1024] 3MiB 5.34M/s 1.5MiB 2.29M/s 768KiB 2.1M/s 384KiB 888K/s 192KiB 470K/s 96KiB 233K/s
./flashbench --open-au-nr=1 --random /dev/mmcblk0p3 -O --erasesize=$[6144 * 1024] --blocksize=$[96 * 1024] 6MiB 6.97M/s 3MiB 2.9M/s 1.5MiB 2.61M/s 768KiB 1.49M/s 384KiB 881K/s 192KiB 442K/s 96KiB 216K/s
./flashbench --open-au-nr=1 --random /dev/mmcblk0p3 -O --erasesize=$[8192 * 1024] --blocksize=$[64 * 1024] 8MiB 7.63M/s 4MiB 3.33M/s 2MiB 3.71M/s 1MiB 2.58M/s 512KiB 1.19M/s 256KiB 604K/s 128KiB 282K/s 64KiB 242K/s
hope these numbers help somehow.. i'm lost in numbers now :)
The only thing you can tell from these numbers is that 1MB erase block size is likely correct, because the performance numbers are halved with every line below 1MB but are fairly constant above that.
Arnd
Hi
On 11/07/11 21:25, Arnd Bergmann wrote:
BTW: must these tests been done on a partition which is 4MiB aligned?
Yes, the partition must be aligned to the erase block size, in this case probably 1MB. You can add something like '--offset=$[123 * 512]' to move the start of the test run 123 sectors into the drive to correct this.
If the partition is misaligned, that will improve the measurement, but the numbers here indicate that the alignment is indeed at least 1MB.
I see. Ok, partitions on this card were not aligned. I redo the tests
just to be sure, here's my partition table:
sfdisk -uS -l /dev/mmcblk0
Disk /dev/mmcblk0: 121008 cylinders, 4 heads, 16 sectors/track Warning: The partition table looks like it was made for C/H/S=*/128/32 (instead of 121008/4/16). For this listing I'll assume that geometry. Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System /dev/mmcblk0p1 1 614399 614399 83 Linux /dev/mmcblk0p2 614400 819199 204800 83 Linux /dev/mmcblk0p3 819200 1851391 1032192 82 Linux swap / Solaris /dev/mmcblk0p4 1851392 7364607 5513216 83 Linux
as long as it is possible to divide the starting point of a partition by 4MiB == 8192 sectors of 512 byte it's aligned. true?
The erase block size is usually the point where the last column has the largest drop, in this case between 1MB and 512KB, so the erase block is 1MB.
The page size is probably 8KB according to this, i.e. the other drop.
What the number show is:
- It takes around 1.29ms to read 1KB within a page
- It takes around 1.46ms to read 1KB across a page boundary
- It takes around 1.97ms to read 1KB across an erase block
aah, i understand. Thank you for explanation!
means the card can handle only 1 block at once, does it? because performance is constant only with 1 block and 4MiB erase-block should be fine (?)
Yes, this is the main problem with Kingston cards. You can see the effect all over the table in https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey for every Kingston SD card.
Ok, i don't buy kingston cards then
I have now 11 different cards on my desk..: 5x sandisk, 2x transcend, 1x emtec, 4x lexar class 2, 4, 6 .. 4, 8, 16GB going to start tests and send over..
I think this has more to do with the alignment of the first erase block. If the partition start is not aligned to a full multiple of the erase block size, larger blocks are simply faster because you actually end up writing full erase blocks, while writing 1MB across two partial erase blocks is rather slow.
ok, i understand. So these values are more or less unusable,. I will redo the tests then.
hmm, does that turbo-boost at 64KiB mean that's the correct page size?
No, you can see this effect for very many media from different vendors. I have two possible explanations for this:
- The cards optimize for the behaviour of microsoft windows, which is
known to normally write exactly 64KB at once. 2. It's an artifact of the way that the Linux block layer works.
Doh. Well, i don't go to switch to microsoft windows *g* can't they simply write somewhere the specifications, just like on every bottle of orange juice? :)
This mainly shows how Kingston cards suck with random I/O: You cannot even write a single erase block efficiently doing random writes with an erase block. When you have this behaviour, doing more --random tests does not help you any further.
ok, good to know
i used a USB-adapter for these tests now:
./flashbench -a /dev/sda3 --open-au-nr=1 --count=100 align 134217728 pre 2.57ms on 2.96ms post 2.56ms diff 399µs align 67108864 pre 2.7ms on 3.12ms post 2.56ms diff 486µs align 33554432 pre 2.77ms on 3.16ms post 2.62ms diff 458µs align 16777216 pre 2.76ms on 3.21ms post 2.66ms diff 495µs align 8388608 pre 2.81ms on 3.17ms post 2.6ms diff 469µs align 4194304 pre 2.63ms on 3.04ms post 2.54ms diff 459µs align 2097152 pre 2.76ms on 3.12ms post 2.53ms diff 476µs align 1048576 pre 2.67ms on 3.01ms post 2.59ms diff 378µs align 524288 pre 2.54ms on 2.55ms post 2.56ms diff -2071ns align 262144 pre 2.54ms on 2.55ms post 2.56ms diff -959ns align 131072 pre 2.55ms on 2.55ms post 2.56ms diff -4413ns align 65536 pre 2.53ms on 2.55ms post 2.58ms diff -3958ns align 32768 pre 2.54ms on 2.55ms post 2.56ms diff 2.15µs
ok, still 1MiB erase block 64KiB page size?
but looks not *that* stable with 1MiB:
./flashbench /dev/sda3 --open-au-nr=1 -O --random --erasesize=$[1024 * 1024] --blocksize=$[64 * 1024] 1MiB 10.5M/s 512KiB 2.27M/s 256KiB 2.12M/s 128KiB 770K/s 64KiB 419K/s
./flashbench /dev/sda3 --open-au-nr=1 -O --random --erasesize=$[1024 * 1024] 1MiB 2.84M/s 512KiB 2.25M/s 256KiB 2.13M/s 128KiB 775K/s 64KiB 420K/s 32KiB 186K/s 16KiB 88K/s
./flashbench /dev/sda3 --open-au-nr=1 -O --random --erasesize=$[1024 * 1024] 1MiB 2.75M/s 512KiB 2.25M/s 256KiB 2.15M/s 128KiB 770K/s 64KiB 419K/s 32KiB 186K/s 16KiB 88.2K/s
./flashbench /dev/sda3 --open-au-nr=1 -O --random --erasesize=$[1024 * 1024] --blocksize=$[64 * 1024] 1MiB 2.68M/s 512KiB 2.28M/s 256KiB 2.14M/s 128KiB 773K/s 64KiB 420K/s
./flashbench /dev/sda3 --open-au-nr=1 -O --random --erasesize=$[1024 * 1024 *2] --blocksize=$[64 * 1024] 2MiB 4.31M/s 1MiB 6.15M/s 512KiB 4.96M/s 256KiB 1.61M/s 128KiB 855K/s 64KiB 377K/s
peter
On Tuesday 12 July 2011, Peter Warasin wrote:
On 11/07/11 21:25, Arnd Bergmann wrote:
BTW: must these tests been done on a partition which is 4MiB aligned?
Yes, the partition must be aligned to the erase block size, in this case probably 1MB. You can add something like '--offset=$[123 * 512]' to move the start of the test run 123 sectors into the drive to correct this.
If the partition is misaligned, that will improve the measurement, but the numbers here indicate that the alignment is indeed at least 1MB.
I see. Ok, partitions on this card were not aligned. I redo the tests
just to be sure, here's my partition table:
sfdisk -uS -l /dev/mmcblk0
Disk /dev/mmcblk0: 121008 cylinders, 4 heads, 16 sectors/track Warning: The partition table looks like it was made for C/H/S=*/128/32 (instead of 121008/4/16). For this listing I'll assume that geometry. Units = sectors of 512 bytes, counting from 0
Device Boot Start End #sectors Id System /dev/mmcblk0p1 1 614399 614399 83 Linux /dev/mmcblk0p2 614400 819199 204800 83 Linux /dev/mmcblk0p3 819200 1851391 1032192 82 Linux swap / Solaris /dev/mmcblk0p4 1851392 7364607 5513216 83 Linux
as long as it is possible to divide the starting point of a partition by 4MiB == 8192 sectors of 512 byte it's aligned. true?
Yes, correct.
means the card can handle only 1 block at once, does it? because performance is constant only with 1 block and 4MiB erase-block should be fine (?)
Yes, this is the main problem with Kingston cards. You can see the effect all over the table in https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey for every Kingston SD card.
Ok, i don't buy kingston cards then
I have now 11 different cards on my desk..: 5x sandisk, 2x transcend, 1x emtec, 4x lexar class 2, 4, 6 .. 4, 8, 16GB going to start tests and send over..
Ok, very cool.
I'm especially interested in the Lexar ones, because I don't have a good sample of those yet and they are one of the four main manufacturers of flash chips (samsung, sandisk/toshiba, intel/micron/lexar, hynix).
Sandisk occasionally does improvements to their controllers and it's interesting to see their progress. Transcend has some good and some bad runs, they must buy their hardware from varying manufacturers.
I haven't seen any emtec cards, so that will be a good addition as well.
i used a USB-adapter for these tests now:
./flashbench -a /dev/sda3 --open-au-nr=1 --count=100 align 134217728 pre 2.57ms on 2.96ms post 2.56ms diff 399µs align 67108864 pre 2.7ms on 3.12ms post 2.56ms diff 486µs align 33554432 pre 2.77ms on 3.16ms post 2.62ms diff 458µs align 16777216 pre 2.76ms on 3.21ms post 2.66ms diff 495µs align 8388608 pre 2.81ms on 3.17ms post 2.6ms diff 469µs align 4194304 pre 2.63ms on 3.04ms post 2.54ms diff 459µs align 2097152 pre 2.76ms on 3.12ms post 2.53ms diff 476µs align 1048576 pre 2.67ms on 3.01ms post 2.59ms diff 378µs align 524288 pre 2.54ms on 2.55ms post 2.56ms diff -2071ns align 262144 pre 2.54ms on 2.55ms post 2.56ms diff -959ns align 131072 pre 2.55ms on 2.55ms post 2.56ms diff -4413ns align 65536 pre 2.53ms on 2.55ms post 2.58ms diff -3958ns align 32768 pre 2.54ms on 2.55ms post 2.56ms diff 2.15µs
ok, still 1MiB erase block 64KiB page size?
I don't see this from these numbers. In about a third of the cases, the -a test doesn't give you the right answer. In this case, it seems to show the right erasesize, but not the page size. Negative numbers in the last column indicate that it doesn't actually do what we expect, i.e. reading across a 32KB boundary is actually faster than reading an aligned block.
Using --pagesize=1024 in the -a test gives you the best results normally.
but looks not *that* stable with 1MiB:
./flashbench /dev/sda3 --open-au-nr=1 -O --random --erasesize=$[1024 * 1024] --blocksize=$[64 * 1024] 1MiB 10.5M/s 512KiB 2.27M/s 256KiB 2.12M/s 128KiB 770K/s 64KiB 419K/s
./flashbench /dev/sda3 --open-au-nr=1 -O --random --erasesize=$[1024 * 1024] 1MiB 2.84M/s 512KiB 2.25M/s 256KiB 2.13M/s 128KiB 775K/s 64KiB 420K/s 32KiB 186K/s 16KiB 88K/s
This is expected: Since you used --random, this card will be really slow all the time, it simply cannot do random access. The first run is fast when the card is in a good state initially, but on the second run, it still needs to garbage-collect data from the last run.
I would expect that doing the same test without random on this card looks like
1MiB 10.5M/s 512KiB 8.1M/s 256KiB 8.0M/s 128KiB 7.8M/s 64KiB 8.2M/s 32KiB 6.1M/s 16KiB 4.0M/s 8KiB 1.9M/s 4KiB 980K/s 2KiB 483K/s
(entirely guessed)
Arnd
flashbench-results@lists.linaro.org