[vox-tech] random # gen seeds

[Matt Holland]

The program is a fairly simple stochastic simulation -- it does the 
simulation, collects the information I want, and spits it out to 
standard output.  I've been automating multiple runs of the simulation 
from within a Perl script, which is how I noticed the 6 runs per second 
phenomenon.  I realize that I could change the design so that several 
simulations are run from another block of C code that sets the seed less 
frequently, but in my opinion the current design is the most natural, 
and the most convenient from the perspective of automation.

Anyway, Mark's gettimeofday suggestion seems to have resolved the 
problem.  As long as I don't find a machine that can run sims more than 
once per microsecond, I should be fine!

Matt

msimons@moria.simons-clan.com wrote:

> On Wed, Mar 13, 2002 at 08:46:07PM -0800, Mark K. Kim wrote:
> 
>>gettimeofday returns a structure with seconds as well as microseconds.
>>You can use the microseconds portion as the seed.  However, there is a
>>resolution issue with microseconds, which may or may not be a problem, so
>>you probably want to mix up the seconds with the microseconds somehow.
>>
>>Also, you can read /dev/random.
>>
>>On Wed, 13 Mar 2002, Matt Holland wrote:
>>
>>>I need to generate more than one random number generator seed per second
>>>within a C program (I have a program that runs about 6 times a second,
>>>and I need unique seeds for each run).  time(0) only gives me a
>>>resolution of 1 second... any suggestions?
>>>
> 
> Matt,
> 
>   Both of Mark's suggestions are good (gettimeofday, /dev/random)
> 
>   However, I doubt your application needs data from /dev/random and would
> recommend using urandom instead (man urandom(4) for details).  When using
> /dev/random there is a risk that if you try to run get too much from it 
> you will starve "the entropy pool" and your application will lock up 
> waiting for more entropy.
>   So if possible the best option would be reading data from /dev/urandom.
> 
>   I would also suggest that you reconsider how your overall application 
> works... possibly try to restructure it so that you start one application
> which gets one random seed and does whatever you wanted to do 6 times
> a second itself, instead of starting hundreds of very short lived 
> processes.
>   Can you provide any more details about what you are doing?
> 
>     TTFN,
>       Mike
> 
> 
> from urandom(4):
> #      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  to /dev/random will block until additional environ-
> #      mental noise is gathered.
> #
> #      When read, /dev/urandom device will return as  many  bytes
> #      as are requested.  As a result, if there is not sufficient
> #      entropy in the entropy pool, the returned values are theo-
> #      retically  vulnerable  to  a  cryptographic  attack on the
> #      algorithms used by the driver.  Knowledge  of  how  to  do
> #      this is not available in the current non-classified liter-
> #      ature, but it  is  theoretically  possible  that  such  an
> #      attack  may  exist.  If this is a concern in your applica-
> #      tion, use /dev/random instead.
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech
>