l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2002 Mar 15 11:45

The following is an archive of a post made to our 'vox-tech mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox-tech] random # gen seeds
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox-tech] random # gen seeds

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!


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

vox-tech mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
O'Reilly and Associates
For numerous book donations.