On a 386SX-16?
My guess: value*clockchange*arch = 0.000008*(75/16)*(2*1.5) = 0.0001
Now, multiply that by the number of calls. At 1000/second, the system
would be spending maybe 10% of the time getting entropy. That is
of course a wild guess, but it's better than a BogoMIPS-based estimate.
While I was doing my benchmarking, I tried my hardest to generate as
many entropy samples as possible. The best I could do was about 100
calls per second. So on a 386SX-16, using your estimates, we're talking
about 1% of the time --- and that was when the hard disk was going full
bore. (And on a 386SX-16, it's likely that your disk transfer will
probably be much less, so the number of entropy cycles will probably
much less than 100/second.)
It shows one aspect of performance. You could get a better picture
by running a CPU benchmark at the same time.
OK, let's take a look at the facts, and do some quick calculations.
Using the average of 600 cycles/per call, and your 100 calls/second,
then on a 50 MHz Pentium, the overhead is 0.12% of the CPU. If we
assume your architecture multiplier of (2*1.5), then on a 386SX-16 the
CPU overhead is approximately 1.1%. Permit me not to be terribly
impressed. (Again, on a 386-SX the I/O bandwidth on the bus will likely
be bad enough that you won't be able to get 100 calls to
end_request()/second.)
> It might be possible to move the complicated hash function (which is
> used when you actually read from /dev/random) out to a user-mode daemon,
> but you wouldn't be able to move out to a library, because of user to
> user security concerns. (A random user program can't be allowed to
> directly see random pool, since that would completely compromise the
> security of the random pool.) The real problem with a user-mode daemon,
With a library alone:
You wouldn't keep the old pool after giving it to a user.
With a library alone, then the user program could access the pool
directly, this violating the pool's security. We can't restrict the
user program to only using the library abstraction interface. This is
why your proposed library solution is completely inadequate.
Since the networking protocols require SHA and MD5, those must be
in the kernel. The particular way that Linux boots is not an ISO
or RFC anything, so that can be changed. It should be simple to
write a program that replaces the gzip CRC (and magic) with something
else. Maybe the FSF would even accept an alternate algorithm to be
used only when gzip is explicitly told to do so. For now though, a
simple hack_gz_for_linux could switch to MD5 or SHA.
The point of this statement is that the SHA checksum is approximately
6796 bytes of text. This is out of the 10385 bytes of text used by the
random driver. So if the network code in the future requires SHA, then
the total net savinges of ripping out the random driver is an amazing
3589 bytes --- less that one page.
It continues to amaze me how people like to rip apart other people's
code without even stopping to do any real thinking and investigation.
After all this complaining and kvetching about kernel bloat and
overhead, when we actually take a close look at it, it's not all that
bad at all.
- Ted