#28 Add a multi thread option for -t

[Ralf Naujokat]

Hi.

I've bought myself some new hardware,
a fast PCI 5 SSD, that should be able to perform reads with about 14 GB/s.

I tried to verify that with hdparam -t {device},
but disappointingly I only got values of about 7 GB/s.
Some tries with reading and writing with dd got the same poor result.
I tried adding --direct because i thought ext4 could slowing this,
but nothing changed.

Then I suspected that I had configured something incorrectly
and even contacted support, but that was not really helpful.
After spending some time with google i found some guys talking about
multiple simultaneous reading tasks.

So i tried
for ((i=1;i<=10;i++)); do sudo hdparm -t --direct /dev/nvme0n1 & done
and got 10 parallel tasks, each reporting a reading performance with about 1400 MB/s.
That now adds up to about the expected read performance.

May be it is possible to add an option to force a muti threaded
read test to get better results.

kind regards
Ralf

[Mark Lord]

I dunno. I'm kinda torn by this request. How would an extreme multi-threaded read test measure anything relevant to Real Life? The existing -t flag is for measuring sequential read speed, giving an indication of the throughput that real apps might expect to achieve. Eg. KVM or virtualbox saving a multi-GB VM state.

Doing simultaneous over-lapping runs of the exact same data blocks from the drive isn't going to be relevant, and might just end up with most threads reading from the on-drive cache, rather than the flash memory.

[Ralf Naujokat]

Your points about real life and caching are of course valid, but to me it looks
as if a single thread cannot achieve the full possible utilization,
and therefore the test actually returns too low values.
At least lower than the advertising promises. ;-)
But it's up to you.

[Mark Lord]

I actually ran into this myself last fall, when I got a new notebook computer and then tested various NVMe drives for use with it.

There are existing Linux utilities to do various configurations of multi-threaded I/O benchmarks, and they do it reasonably well. Eg. KDiskMark on KDE/Plasma, or the Gnome disk utility.

The subject of benchmarking drives is sufficiently complex, I don't think it belongs in a low-level utility like hdparm, which is used on everything from small micro-controllers, RaspberryPi's, etc.. up to IBM mainframes. It is intentionally compact, with very few build dependencies, and focuses on being a quick and simple swiss-army knife. Not the 112-blade 2lb monsters that some people take camping. :)