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