> 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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
