i...@bsdimp.com (Warner Losh) writes:
>I've not used any m.2 devices. These tests were raw dd's of 128k I/Os
>with one thread of execution, so no effective queueing at all.
gossam: {4} dd if=/dev/rdk0 bs=128k of=/dev/null count=100000
100000+0 records in
100000+0 records out
13107200000 bytes transferred in 8.766 secs (1495231576 bytes/sec)
That's about 50% below the nominal speed due to syscall overhead
and no queuing. With bs=1024k the overhead is smaller, the device
is rated at 2.5GB/s for reading.
gossam: {7} dd if=/dev/rdk0 bs=1024k of=/dev/null count=10000 &
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 4.371 secs (2398938458 bytes/sec)
>Just ran a couple of tests and found dd of 4k blocks gave me 160MB/s,
>128k blocks gave me 600MB/s, 1M blocks gave me 636MB/s. random
>read/write with 64 jobs and an I/O depth of 128 with 128k random reeds
>with fio gave me 3.5GB/s. This particular drive is rated at 3.6GB/s.
Yes, those are similar results. With multiple dd's the numbers almost
add up until the CPUs become the bottleneck.
However, I was looking for devices that even fail the dd test with
large buffers. Apparently there are devices where you must use
concurrent I/O operations to reach their nominal speed, otherwise
you only get a fraction (maybe 20-30%).
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
