Maybe better advice is to never use /dev/random except when you need it for cryptographic security (ie, generating some random data for keys).
If you want to test stuff with random data, use /dev/urandom (a pseudorandom random number generator device, which never runs out of data and can provide reasonable-quality "random" data, just not for cryptographic needs). urandom will also be faster because of this -- it doesn't need to wait for "truly random" data to be accumulated. There are other options too, depending on your needs. The Math::Random namespace has tons of these, including one that I've worked on (Math::Random::ISAAC) and some others I've toyed with, notably the Mersenne Twister (Math::Random::MT) and TT800 algorithms (related to the Mersenne Twister; see Math::Random::TT800) If you need random data, you can also get it from interrupt timings. See Math::TrulyRandom for details. It's always good to heed this advice. Do NOT use /dev/random unless you really need random data! Entropy (especially on smaller less-used systems) can be really difficult to gather. On the other hand, this is something a Hardware Random Number Generator (HRNG) is great for -- some Trusted Platform Module chips (including the one on my laptop motherboard) support this feature. Hopefully some others on the list learn from your experiences, Craig. Thanks for sharing. Cheers, Jon On Tue, Nov 10, 2009 at 10:01 PM, <[email protected]> wrote: > Many of you know that the random number generator /dev/random > is subject to delays when it has "not accumulated enough entropy", > which is to say randomness. These delays are said to be longer > on Linux /dev/random that on some other Unices. They occur > particularly after a system is booted, which I hear is a regular > occurrence on some smoke-test systems. > > But I bet many of you will be surprised by the magnitude of the > delays that can occur. > > Recently one perl tester's Linux system tested my module IPC::MMA > version 0.58, which used /dev/random to drive testing, to produce > report 5888084. It took 22320 wallclock seconds to complete the > tests: 6.2 hours. > > A few days later the same system tested version 0.58001, which > differs from 0.58 mainly in using /dev/urandom which is not subject > to "entropy delays". Report 5889682 shows that it took 5 wallclock > seconds. > > Anyway, I found it interesting, > Craig MacKenna > >
