3 ms·
On your typical Linux host you can just run `hdparm -T $BLKDEV` (e.g. BLKDEV=/dev/sda here): # hdparm -T /dev/sda /dev/sda: Timing cached reads: 1911
by pengaru 3y ago
On your typical Linux host you can just run `hdparm -T $BLKDEV` (e.g. BLKDEV=/dev/sda here):
# hdparm -T /dev/sda
/dev/sda:
Timing cached reads: 19110 MB in 1.99 seconds = 9582.36 MB/sec
Which quickly tells me single-threaded memory bandwidth of ~10GB/s (i7 X230 ThinkPad w/2x8GB SODIMMs(16GB))
It's often interesting to run multiple of these simultaneously and observe how much the per-core and aggregate bandwidth increases/decreases with increased parallelism.
- dietr1ch 3y agoI was curious and get vastly different numbers on my machine. I grabbed this and compiled it with gcc https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/blob/master/2024/01/13/bandwidth.cpp https://github.com/lemire/Code-used-on-Daniel-Lemire-s-blog/... g++ -std=gnu++17 -O3 -o bandwidth bandwidth.cpp && ./bandwidth > 50.0 > ... 50 GB/s, it drops slowly to 45GB/s with 32 threads) sudo hdparm -T /dev/nvme0n1 > Timing cached reads: 58222 MB in 1.99 seconds = 29230.67 MB/sec It's a good lower bound though
- pengaru 3y agoThat makes me wonder how much sys-wide kernel<->userspace and/or glibc copying performance is sitting on the table there, to be potentially reclaimed with an optimized build and/or vulnerability mitigations disabled?