Actual throughput vs reported

[Aaron Toponce]

On Tue, Oct 02, 2012 at 09:36:23AM +0100, Daniel Silverstone wrote:
> Are you decoupling ekeyd from the pool by use of ekeyd-egd-linux?
> 
> If not then you will be suffering from overfilling the pool wasting entropy.
> 
> The EGD-Linux tool uses the thresholds so as to not waste entropy, whereas
> ekeyd just dumps anything it gets into the pool when it gets it.
> 
> In brief, I think if you have more than a passing requirement for one device,
> you should be using EGD mode to ensure that things are buffered and consumed
> more efficiently.

I'm not sure I'm following. If I exhaust the pool, then I should be able to
see the rate at which it fills. I get with the entropy keys alone:

    $ pv -a < /dev/random > /dev/null
    [8.22kB/s]

That is with all 5 keys plugged in. If I turn on haveged with the Raspberry
Pi, then I see:

    $ pv -a < /dev/random > /dev/null
    [149kB/s]

So, are you suggesting that installing ekeyd-egd-linux will cause the pool
to fill faster? Because it appears to me that when I exhaust the pool, the
best that the keys can do to fill it on the Raspberry Pi is ~8.22 KBps,
which frankly, sucks. Installing only ekeyd, and using all 5 on my laptop,
on the other hand, gives the performance of ~20KBps, as expected.

So, something is up with the Pi, is my guess. My understanding of
ekeyd-egd-linux, is that it is a client application to connect to a running
ekeyd instance, and fill the pool, which is something I plan on deploying,
but need to know that the keys can support 20 KBps on my Raspberry Pi
first.

-- 
. o .   o . o   . . o   o . .   . o .
. . o   . o o   o . o   . o o   . . o
o o o   . o .   . o o   o o .   o o o
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 519 bytes
Desc: not available
URL: <http://lists.simtec.co.uk/pipermail/entropykey-users/attachments/20121002/ca19230d/attachment.pgp>