I was doing some hard drive speed benchmarking and decided to try the following command to see what would happen:

dd if=/dev/zero of=/dev/null

After I canceled it, I got:

(269 GB, 251 GiB) copied, 107.101 s, 2.5 GB/s

If I change the bytesize or count, I get different results:

dd if=/dev/zero of=/dev/null bs=4096 count=2000
(8.2 MB, 7.8 MiB) copied, 0.00134319 s, 6.1 GB/s

dd if=/dev/zero of=/dev/null bs=16384 count=2000
(33 MB, 31 MiB) copied, 0.00305674 s, 10.7 GB/s

Since I'm not reading or writing to any real drive, what am I actually measuring here? How fast the CPU can generate zeros and move them into a virtual trash can? This actually seems really slow to me for just that.

Does it hit the RAM? Does the motherboard bus come into play?

Does this test have any practical benchmarking applications (ie. comparing different generation processors)?

Is the result here the fastest I/O the system could ever achieve, even if the real disks were (theoretically) infinite speed?

What does dd if=/dev/zero of=/dev/null actually measure?


This does not benchmark your hard drive but just 1 thead of your CPU (as dd is using a single thread process)

What you do is basically, ask your processor to send as much zeros to a black hole as fast as it can.

If I do the same as you in my machine I got the following:

dd if=/dev/zero of=/dev/null bs=16384 count=2000
2000+0 records in
2000+0 records out
32768000 bytes (33 MB, 31 MiB) copied, 0,018317 s, 1,8 GB/s

In a few word, you have a better CPU than mine ;-)

Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz

  • 7.5 GB/s on Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz. Very cool.
    – Stewart
    Feb 21 at 20:44

You asked

What does dd if=/dev/zero of=/dev/null actually measure?

You're measuring how fast the OS can read blocks of 512 bytes of zeros and discard them. It's not efficient to read such small blocks, which is why you get better throughput for larger block sizes.

For real-world use on Linux-based systems you should also consider using cat instead of dd - cat is far easier to use and it (very) rarely goes slower than an optimised dd

  • 2
    In particular, copying blocks of 512 bytes between the userspace program and the kernel through the usual system calls. Which you also have to do when writing an actual file, but it's perhaps worth mentioning since the system call overhead is likely to be much bigger than the cost of just copying a block of 512 within the kernel or within userspace.
    – ilkkachu
    Jan 15 at 12:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.