On Monday 11 July 2011 21:35:17 Peter Warasin wrote:
$ ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O --erasesize=$[6144 * 1024] --blocksize=$[96 * 1024]
6MiB 1.92M/s 3MiB 2.17M/s 1.5MiB 2.38M/s 768KiB 1.87M/s 384KiB 986K/s 192KiB 869K/s 96KiB 724K/s
$ ./flashbench --open-au-nr=2 --random /dev/mmcblk0p3 -O --erasesize=$[8192 * 1024] --blocksize=$[64 * 1024]
8MiB 2.95M/s 4MiB 5.6M/s 2MiB 3.79M/s 1MiB 4.21M/s 512KiB 2.91M/s 256KiB 1.2M/s 128KiB 967K/s 64KiB 601K/s
quite stable
From these numbers, it's definitely clear that there is no factor 3 in it, the erase block size has to be either 4MB or 8MB.
Since you asked about the alignment in the other thread: What is the alignment of this partition? Do the numbers change if you align the block to an odd number of 4MB blocks (counting from the start of the card)?
That is usually the best way to find the true erase block size.
i did also -a 256KiB is quite good, is it?
The -a test is not about good or bad, it's about finding the cutoff between short and long delays when reading across a boundary.
./flashbench -a /dev/mmcblk0p3 --open-au-nr=2 -b 1024 align 134217728 pre 1.19ms on 1.46ms post 904µs diff 414µs align 67108864 pre 1.27ms on 1.72ms post 1.02ms diff 573µs align 33554432 pre 1.19ms on 1.58ms post 890µs diff 539µs align 16777216 pre 1.13ms on 1.41ms post 866µs diff 414µs align 8388608 pre 1.09ms on 1.37ms post 915µs diff 371µs align 4194304 pre 1.04ms on 1.25ms post 993µs diff 239µs align 2097152 pre 1.05ms on 1.09ms post 1.07ms diff 29.1µs align 1048576 pre 1.03ms on 1.07ms post 1.05ms diff 30.2µs align 524288 pre 1.04ms on 1.08ms post 1.06ms diff 29µs align 262144 pre 1.01ms on 1.05ms post 1.05ms diff 16.2µs align 131072 pre 1.04ms on 1.06ms post 1.05ms diff 17.9µs align 65536 pre 1.03ms on 1.05ms post 1.05ms diff 15.6µs align 32768 pre 1.04ms on 1.07ms post 1.06ms diff 16.1µs align 16384 pre 1.02ms on 1.06ms post 1.04ms diff 27.2µs align 8192 pre 1.02ms on 1.02ms post 1.02ms diff 3.94µs align 4096 pre 1.02ms on 1.02ms post 1.01ms diff 6.89µs align 2048 pre 1.01ms on 1.03ms post 1.02ms diff 14.3µs
What you can see here is that there is a difference at 16KB, 512KB, and 4MB blocks, so these are some internal properties of the card. The numbers get more stable if you use --count=100 or so, it will take a lot longer and average out the results then. This indicates 4MB erase blocks. Look at the last column in the 4MB and 2MB row.
what i also noticed on this card is that the card is running with legacy timing instead of high-speed:
I don't really know. Best ask this question on the linux-mmc mailing list.
just to notice, i will then ask also on linux-mmc list:
i forced setting the card in high-speed mode and noticed that:
card->sw_caps.hs_max_dtr = 0
which is the max bus speed, *i think*. when i override that i get:
mmc0: Problem switching card into high-speed mode! mmc0: host does not support reading read-only switch. assuming wr ite-enable.
mmc0: new SDHC card at address e624
so most probably the card is really not a high-speed card.
right..
You can pass module options through the boot loader, in the kernel command line, like 'modulename.option=value'.
yes, i know that.. i see only no way to understand if the card actually is dma or pio i only found out how to disable dma (which i don't want of course)
Unlike CF cards, an SD card doesn't know anything about DMA or PIO mode, that is just a property of the controller.
Also, there is no need to run the SD card test on the target hardware. Best do the same test on a PC with a USB card reader or builtin SD card slot and see if the numbers are much different. If everything's faster but the behaviour otherwise the same, there is probably also a bug in the host driver.
we already did that, also on different hardware and different kernels with linux it always differs, but it is always slow. i was very close to say the card is crap, but it's fast with macosx, so i thought card must be ok. well i see now, it depends on many factors :)
but in order to get *bonnie-values* like on macosx, it would must be kind of 9x faster. i mean.. on linux it is about 10% as on macosx. well, i start to think now that maybe bonnie is a lot different on mac and as you said bonnie isn't that good to use on SD-cards, well, maybe those numbers make no sense at all then. however, it is slow and freezing the system, so there is something wrong :)
Still, this could be anything. Bonnie is a high-level benchmark, so this could all just mean that MacOS is doing internal write-caching for SD cards while Linux does less of that.
What would be really interesting is to use flashbench on macos, if you can get that to build and macos supports O_DIRECT.
trying different SD cards now. we will buy as much as different cards as we find in local stores tomorrow and i will send results, only tell me please which values are of interest.. i did not yet really figure out how to read the results
Ok. The numbers I'm usually interested in are:
* erase block size (smaller is better, lower than 4MB is hard to find on 4GB+ cards) * maximum throughput in MB/s * page size (lower is better, 4KB is ideal but rare) * number of open erase blocks (should have at least 5, more for large erase blocks) * should do random writes just fine.
The very easy smoke test is
flashbench --open-au --open-au-nr=5 --blocksize=2048 --random
Look at how the numbers go down. Ideally, they should stay at multiple MB/s all the way down to the 16KB row, or lower. If they behave like the Kingston card you tested earlier, they are completely useless for Linux.
Arnd