On Fri, Mar 25, 2005 at 04:50:16PM -0600, Kim Phillips wrote:> I did some tests and found that the udelay(200) call in hw_random.c is > not good for extreme RNG consumption. Whether or not such extremes > occur in real life, on the mpc8541, /dev/hwrandom is an order of > magnitude slower than /dev/random, and two orders of magnitude slower > than /dev/urandom. The hardware RNG is capable of exceeding software > /dev/random speeds plus it would alleviate the core to do other, more > useful things (that's being realistic).

Consider what an RNG does: spews garbage.

In practical applications, you -do not- want to dedicate the machine to spewing garbage. The vast majority of users would prefer to use theirmachines for real stuff. Thus, "extreme RNG consumption" is largelyirrelevant to sane usage.

That said, I cannot remember if the udelay() is hardcoding a policydecision (bad), or required for the hardware.

In any case, it is the wrong solution to simply "turn on the tap" andlet the RNG spew data. There needs to be a limiting factor... typicallyrngd should figure out when /dev/random needs more entropy, or simplydelay a little bit between entropy collection/stuffing runs.