Re: [patch #6797] shred option to use internal RNG

[Steve Schveighoffer]

> From: Pádraig Brady 

> Steven Schveighoffer wrote:
>
> > One thing we have noticed is that shred runs about 90% slower if 
> > /dev/urandom
> > exists versus when it does not.  Researching this, it seems this is because
> > gl/lib/randread.c will use an internal RNG when null is passed into
> > randread_new, and /dev/urandom cannot be opened.
> 
> Yep, I can only get 3MB/s from my /dev/urandom
> However I don't think it's designed for bulk generation of random data.
> I haven't read your patch but it would be great
> if we didn't have another option for this.
> Instead could we use /dev/urandom if available
> just to (periodically) seed our internal PRNG?

Also notice the CPU usage.  On my system, the CPU was pinned.

Adding a seeding with data from /dev/urandom would be a good improvement to the 
patch.  I'm not sure of the best way to do that, it seems that the seeding 
process is internal to the isaac lib.  Would it make a huge difference to seed 
it periodically vs. just once at the beginning?  I'm not a huge statistics or 
random number buff, maybe someone else knows.

-Steve