Camelia, the Perl 6 bug

IRC log for #etools, 2012-04-17

| Channels | #etools index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
14:17 mikemol refreshingapathy: BTW, entbuff is in pretty good shape.
14:18 mikemol If you're going to be generating crypto keys, you might like having it handy to speed that process up.
14:18 refreshingapathy yeeppppp
14:18 refreshingapathy :D
14:20 mikemol Also, I can send you copies of my netcat scripts for shuffling entropy around. The server side of it depends on using Debian's modified version of rngd, though; upstream rngd doesn't have the 'stream' driver.
14:22 refreshingapathy yea, this openvpn thing won't happen until next week anyways
14:32 mikemol Well, that gives you time to charge the buffers. It can take a long time...
14:33 mikemol http://rosettacode.org/cdc3/bin/index.c​gi?hostname=prgmr2.rosettacode.org&​plugin=entropy&timespan=604800&​action=show_selection&ok_button=OK
14:34 mikemol Prior to the 15th, all I had was a bunch of entropy being shoveled from an entropy-rich source at home to my server.
14:34 mikemol Then I added several entbuff instances with something like a total of 12M between them. The charge time can be painfully slow.
14:35 mikemol That said, they're very well behaved; the default setting is to not allow the system entropy to drop below 256 bits. The minimum seen by collectd over the last week was 354 bits.
14:36 mikemol The default settings also don't draw entropy until the system entropy pool is higher than 2048 bits, and you can see that reflected in that graph.
14:37 mikemol Getting it to charge faster proves to be pretty trivial; if I increase the kernel polling time, it charges very fast, and still doesn't dip below the low threshold.
14:39 mikemol The problem with increasing the polling time too far is that writes get wasteful. The kernel doesn't update its entropy count rapidly enough, and several queries for the system entropy level won't show show any change, despite entbuff's writing between each check.
14:41 mikemol Also, the rate boundary where writes get wasteful changes depending on the system. I'm pretty sure it has to do with slop in the memory model, and variables in the kernel entropy pool not being updated atomically.
14:42 mikemol The solution is likely going to consist at least partly of using a different polling rate for reads than for writes.
14:44 mikemol Which means I'm probably going to have to come up with some general solution for scheduling. I'm already not handling print polling rates properly, really.

| Channels | #etools index | Today | | Search | Google Search | Plain-Text | summary