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