On Mon, 28 Feb 2011, Peter St. John wrote:
The use of the system resource /dev/random is more for cryptography, than for scientific simulations. Some application like SSH is blocking (in Stuart's situation) when the entropy pool is empty.Peter
Find attached a nearly complete solution. This is a "one liner" (almost) xinetd daemon that will read and spit out a four byte uint from /dev/urandom over a network socket connection to port 8885. Install the (bash) script on your head node, which hopefully is on an ethernet and has a keyboard and has enough boot-time entropy to make /dev/urandom work. Installation and testing instructions are included, sort of, but I am NOT providing a tutorial on security and ports and allowed networks, so if you don't want everybody on the internet to be able to get random numbers from your server, you'll have to figure out how to take the appropriate steps on your own (it's not difficult, lines in the xinetd config and/or additions to the iptables firewall rules will do it). The only other thing you'll need (that I'm not providing) is a script or binary on the client side that will connect to the daemon, send it CR/LF, read the uint return, and write it to e.g. /dev/random if that's what it takes to build up enough entropy. Note well that there isn't any reason I can think of to do this a uint at a time other than it was a convenient increment for reseeding, nothing more. So you can increase the size of the dd block to a full page or even more if you like, for substantially greater efficiency. Note well that this is just one way to do it. Perl would let you be more sophisticated (bash is a crude tool and can't cope with binary). C is far more elegant, and you can write a C-based daemon that would seed from /dev/random, use a really good rng, and optionally maintain a self-avoiding table of rands it has returned if you want to use the return as a seed. Even with the current daemon, you can make it read in the requested number of random bytes and return it. Tweak away. rgb
On Mon, Feb 28, 2011 at 4:41 AM, Heiko Bauke <[email protected]> wrote: Hi, On Sun, 27 Feb 2011 11:48:28 -0500 (EST) "Robert G. Brown" <[email protected]> wrote: > The solution for nearly anyone needing large numbers of fast, high > quality random numbers is going to be: Use a fast, high quality > random number generator from e.g. the Gnu Scientific Library, and > >>seed<< it from /dev/random, ensuring uniqueness of the seed(s) > >>across the cluster I agree that for Monte Carlo simulations a fast, high quality (pseudo) random number generator (PRNG) is more appropriate than /dev/{u}random. However, seeding a PRNG randomly is imho a missconception. Even though Monte Carlo algorithms utilize a pseudo random resource the final result of a Monte Carlo simulation should be deterministic and reproducible. Therefore, for scientific Monte Carlo applications one should use a known seed. Parallel Monte Carlo applications may derive streams of pseudo random numbers from a common base sequence by splitting and leap frogging, see also http://arxiv.org/abs/cond-mat/0609584 Regards, Heiko -- -- Number Crunch Blog @ http://numbercrunch.de -- Cluster Computing @ http://www.clustercomputing.de -- Random numbers @ http://trng.berlios.de -- Heiko Bauke @ http://www.mpi-hd.mpg.de/personalhomes/bauke _______________________________________________ Beowulf mailing list, [email protected] sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
Robert G. Brown http://www.phy.duke.edu/~rgb/ Duke University Dept. of Physics, Box 90305 Durham, N.C. 27708-0305 Phone: 1-919-660-2567 Fax: 919-660-2525 email:[email protected]
random_daemon.tar.gz
Description: Small xinetd random number daemon.
_______________________________________________ Beowulf mailing list, [email protected] sponsored by Penguin Computing To change your subscription (digest mode or unsubscribe) visit http://www.beowulf.org/mailman/listinfo/beowulf
