Re: Why you don't want to use /dev/random for testing
On Wed, Nov 11, 2009 at 01:04:49PM -0600, David Nicol wrote: there's always http://fourmilab.ch/cgi-bin/Hotbits?nbytes=128fmt=hex although I don't know what their massively parallel availability is. Not much. There's also Net::Random that provides a vaguely reasonable interface to it. -- David Cantrell | Official London Perl Mongers Bad Influence You may now start misinterpreting what I just wrote, and attacking that misinterpretation.
Re: Why you don't want to use /dev/random for testing
I should note, I wrote an article on this awhile back. Take it with a grain of salt, as I'm not an expert in the area; I just wrote bindings for the ISAAC algorithm to Perl. http://jawnsy.wordpress.com/2009/06/04/performance-of-mathrandomisaac/ It compares the performance of multiple different PRNG modules (code for this is in the Math::Random::ISAAC examples/ directory). I've included charts of the distributions generated by them and benchmarks of course.
Re: Why you don't want to use /dev/random for testing
Dear Jonathan, thanks a lot for the link to this very interesting article! However, a more useful graphical representation of the quality of PRNG’s would be to take consecutive pairs of random numbers as the (X,Y) coordinates of a point to plot. Non-uniform distributions are then easily visible to the naked eye. It is hard to see any quality differences in the graphs accompanying this article which are essentially big red rectangles. It is impossible to see with the naked eye whether the fluctuations in these graphs are simply due to randomness or to a shortfall of the associated algorithm. Does someone here happen to have the necessary plotting software at hand to provide these pictures, without too much effort? That would be great! Thank you! Best regards, Steffen 2009/11/11 Jonathan Yu jonathan.i...@gmail.com I should note, I wrote an article on this awhile back. Take it with a grain of salt, as I'm not an expert in the area; I just wrote bindings for the ISAAC algorithm to Perl. http://jawnsy.wordpress.com/2009/06/04/performance-of-mathrandomisaac/ It compares the performance of multiple different PRNG modules (code for this is in the Math::Random::ISAAC examples/ directory). I've included charts of the distributions generated by them and benchmarks of course.
Re: Why you don't want to use /dev/random for testing
The next version of NYTProf supports profiling some 'slow' perl opcodes. I've included the rand opcode for exactly this reason. Tim. On Tue, Nov 10, 2009 at 07:01:38PM -0800, cr...@animalhead.com 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
Re: Why you don't want to use /dev/random for testing
On Wed, Nov 11, 2009 at 10:22:23AM +, Tim Bunce wrote: The next version of NYTProf supports profiling some 'slow' perl opcodes. I've included the rand opcode for exactly this reason. I meant srand (though rand is also included, just in case). Though having just looked at the Configure code and relevant man pages I realise I was misguided. You can't (easily) configure perl to use a random function that uses /dev/random. Tim. Tim. On Tue, Nov 10, 2009 at 07:01:38PM -0800, cr...@animalhead.com 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
Re: Why you don't want to use /dev/random for testing
there's always http://fourmilab.ch/cgi-bin/Hotbits?nbytes=128fmt=hex although I don't know what their massively parallel availability is. Probably less than google charts. -- http://twitter.com/HankSwap tweets approximately every 36 hours using random delays. Promotional excerpts are fair use!
Re: Why you don't want to use /dev/random for testing
On Tue, Nov 10, 2009 at 10:01 PM, cr...@animalhead.com 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. FWIW, I did a visitcpan scan of distributions that match the string /dev/random/ in lib/. No guarantees that they actually *use* it -- they might just mention it in comments/docs, but here's a watch list that might need further exploration: ADAMK/Crypt-DSA-1.16.tar.gz AWKAY/Apache/Apache-SiteControl-1.01.tar.gz AWKAY/Apache2/Apache2-SiteControl-1.05.tar.gz BOBTFISH/Catalyst-Plugin-Session-0.29.tar.gz CHROMATIC/Crypt-CipherSaber-1.00.tar.gz CZBSD/Myco-0.01.tar.gz DAGOLDEN/Getopt-Lucid-0.18.tar.gz DMALONE/Crypt-IDA/Crypt-IDA-0.01.tar.gz DMUEY/Data-Rand-0.0.4.tar.gz FLORA/Net-SSLeay-1.35.tar.gz FREQUENCY/Math-Random-ISAAC-1.001.tar.gz JDHEDDEN/Math-Random-MT-Auto-4.13.00.tar.gz JDHEDDEN/Math-Random-MT-Auto-6.14.tar.gz JHOWELL/FAQ-OMatic-2.717.tar.gz JHOWELL/FAQ-OMatic-2.719.tar.gz JMASON/IPC-DirQueue-1.0.tar.gz MBROOKS/String-Urandom-0.10.tar.gz MSCHOUT/Apache-AuthTicket-0.90.tar.gz MUIR/modules/Qpsmtpd-Plugin-Quarantine-1.02.tar.gz NUFFIN/Crypt-Random-Source-0.03.tar.gz OPI/Apache2-POST200-0.05.tar.gz PTANDLER/PBib/Bundle-PBib-2.08.01.tar.gz PTANDLER/PBib/Bundle-PBib-2.08.tar.gz SMUELLER/Statistics-Test-RandomWalk-0.01.tar.gz SMUELLER/Statistics-Test-Sequence-0.01.tar.gz SOMMERB/Myco-1.22.tar.gz VIPUL/Crypt-Random-1.25.tar.gz ZEFRAM/Data-Entropy-0.005.tar.gz -- David
Re: Why you don't want to use /dev/random for testing
I'm not sure how many of these modules use it -- in particular, I know Math::Random::ISAAC only mentions it in POD. Using /dev/random isn't very portable -- what happens when you're on Windows? On Wed, Nov 11, 2009 at 2:15 PM, David Golden xda...@gmail.com wrote: On Tue, Nov 10, 2009 at 10:01 PM, cr...@animalhead.com 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. FWIW, I did a visitcpan scan of distributions that match the string /dev/random/ in lib/. No guarantees that they actually *use* it -- they might just mention it in comments/docs, but here's a watch list that might need further exploration: ADAMK/Crypt-DSA-1.16.tar.gz AWKAY/Apache/Apache-SiteControl-1.01.tar.gz AWKAY/Apache2/Apache2-SiteControl-1.05.tar.gz BOBTFISH/Catalyst-Plugin-Session-0.29.tar.gz CHROMATIC/Crypt-CipherSaber-1.00.tar.gz CZBSD/Myco-0.01.tar.gz DAGOLDEN/Getopt-Lucid-0.18.tar.gz DMALONE/Crypt-IDA/Crypt-IDA-0.01.tar.gz DMUEY/Data-Rand-0.0.4.tar.gz FLORA/Net-SSLeay-1.35.tar.gz FREQUENCY/Math-Random-ISAAC-1.001.tar.gz JDHEDDEN/Math-Random-MT-Auto-4.13.00.tar.gz JDHEDDEN/Math-Random-MT-Auto-6.14.tar.gz JHOWELL/FAQ-OMatic-2.717.tar.gz JHOWELL/FAQ-OMatic-2.719.tar.gz JMASON/IPC-DirQueue-1.0.tar.gz MBROOKS/String-Urandom-0.10.tar.gz MSCHOUT/Apache-AuthTicket-0.90.tar.gz MUIR/modules/Qpsmtpd-Plugin-Quarantine-1.02.tar.gz NUFFIN/Crypt-Random-Source-0.03.tar.gz OPI/Apache2-POST200-0.05.tar.gz PTANDLER/PBib/Bundle-PBib-2.08.01.tar.gz PTANDLER/PBib/Bundle-PBib-2.08.tar.gz SMUELLER/Statistics-Test-RandomWalk-0.01.tar.gz SMUELLER/Statistics-Test-Sequence-0.01.tar.gz SOMMERB/Myco-1.22.tar.gz VIPUL/Crypt-Random-1.25.tar.gz ZEFRAM/Data-Entropy-0.005.tar.gz -- David
Re: Why you don't want to use /dev/random for testing
On Wed, Nov 11, 2009 at 2:40 PM, Jonathan Yu jonathan.i...@gmail.com wrote: I'm not sure how many of these modules use it -- in particular, I know Math::Random::ISAAC only mentions it in POD. Using /dev/random isn't very portable -- what happens when you're on Windows? Some things may check for it and fall back to other options. Or, as often happens, people release distributions to CPAN without ever knowing (or caring) whether they are portable to Windows. As I said, I just grepped for the string in lib/ as a quick way to get a short list. David
Why you don't want to use /dev/random for testing
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
Re: Why you don't want to use /dev/random for testing
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) Math::Random::MT::Auto another PRNG module. It uses a variety of random data source for seeding, and has a insuperably long period. (But as with any PRNG, not cryptographically suitable.) If you need random data, you can also get it from interrupt timings. See Math::TrulyRandom for details. The Math::Random::MT::Auto POD also lists several truly random data sources.
