I get wildly different real times when I run the following command.

dd if=/dev/random bs=1k count=1 

It doesn' happen for if=/dev/null, nor does it happen for if=/dev/urandom

I've run it 500 times. Here are the general stats (per call). The times are in seconds.

Minimum   Maximum  Average   Median
00.002    89.999   4.50402   2.275 

Does anyone have any suggestions about why this may be happening?
The system is Ubuntu 10.04 desktop. Bash version is 4.1.5(1)
It also shows the similar wild fluctuations in a VirtualBox VM running the same version of Ubuntu.

Here is the actual test code

cp /dev/null "$HOME/dd-random.secs" 
for ((i=100;i<=500;i++)); do
    if   ((i<10))  ;then zi="00$i"
    elif ((i<100)) ;then zi="0$i"
    else                 zi="$i"
    echo -ne "$zi\t" >>"$HOME/dd-random.secs"
    exec 3>/dev/null 4>/dev/null
        { time { dd if=/dev/random bs=1k count=1; } 1>&3 2>&4; } 2>&1 |tail -n 3|tr 'm\n' '\t' |sed -re "s/([0-9])s/\1/g" >>"$HOME/dd-random.secs" 
    exec 3>&- 4>&-
    echo >>"$HOME/dd-random.secs"
  • 1
    Regarding the difference between /dev/random and /dev/random, I highly recommend reading Is a rand from /dev/urandom secure for a login key? (“The short answer is yes. The long answer is also yes.”). May 25, 2011 at 20:15
  • 2
    A minor remark: do not use /dev/null for reading - it is a sink, not a source. For empty (zero) input, use /dev/zero. Sep 29, 2011 at 10:03
  • @rozcietrzewiacz the purpose of copying /dev/null is not to create a endlessly big file filled with zeros but to generate an empty file. So /dev/null can be a source (immediately returning EOF) and is the right one here. However using : > ~/did-random.secs is a clearer way to create or truncate a file.
    – eckes
    Apr 5, 2017 at 8:37

2 Answers 2


That's exactly the difference between /dev/random and /dev/urandom -- random uses the entropy pool, which gathers noise from a bunch of sources and keeps track of "how much" noise is currently in the pool, so random knows how much high-quality randomness it can generate. Since the entropy pool has a finite amount of noise, reading from random might need to block if there isn't enough entropy available. urandom never blocks, but you might get "less random" data from it.

From the random(4) man page:

When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered.

A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver.

  • Thanks Michael.. I actually thought that urandom was the more random (slower) one, so its good to have that cleared up /dev/random is the more random.... There is absolutely no way I would ever have thought that it could/would be that much slower... Just that point alone (90 seconds) implies some serious design intent... I don't know how the entropy is established, but I assume it is related to real-time system activity...
    – Peter.O
    May 25, 2011 at 18:00
  • @fred Reading continuously from /dev/random will consume it really fast; normally apps are only reading small amounts. You can check /proc/sys/kernel/random/entropy_avail to see how much entropy is currently available (in bits) May 25, 2011 at 18:38
  • @fred: The short answer is that you don't use /dev/random. The long answer is this answer. @Michael: I kind of object to “guarantees the output will actually be random”, which is true only for a very particular definition of random which is neither practically nor theoretically useful. May 25, 2011 at 20:15
  • @Michael: Why, if I repeatedly cat /proc/sys/kernel/random/entropy_avail, does the number keep dropping? May 25, 2011 at 20:19
  • @Faheem The number should be fluctuating continuously as the entropy pool changes; it can't actually keep dropping or it would hit 0 and stay there May 25, 2011 at 20:26

From http://en.wikipedia.org/wiki//dev/random#Linux:

"When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered."

Edit: Looks like Michael beat me to it!

  • Aha! thanks... so my bright idea of stopping whatever I could so as to not interfere with the test wasn't so bright after all :)... As soon as I saw the words 'entropy pool', it all made sense... I'd better read the link now...
    – Peter.O
    May 25, 2011 at 17:02

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.