Perl 6 - the future is here, just unevenly distributed

IRC log for #rosettacode, 2012-02-27

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

All times shown according to UTC.

Time Nick Message
00:51 mwn3d_phone joined #rosettacode
01:32 deltree_ joined #rosettacode
02:18 maustin joined #rosettacode
02:27 kpreid joined #rosettacode
03:32 mikemol k, fixed a segfault.
03:38 sorear mikemol: What in RC tends to segfault?
03:39 mikemol My entropy buffer program.
03:39 mikemol Forgot to reset the write pointer in the round-robin buffer when it wrapped.
03:42 mikemol http://rosettacode.org/cdc3/bin/index.c​gi?hostname=prgmr2.rosettacode.org&​plugin=entropy&timespan=3600&ac​tion=show_selection&ok_button=OK
03:42 fedaykin "collection.cgi, Version 3" http://rldn.net/DtkX
03:42 mikemol Working pretty well right now.
03:43 mikemol I've got three boxes sending entropy toward the server, and the server buffer's filling reasonably fast. It's going to try to keep the entropy level north of 2048 bits, and will siphon bits off when it gets north of 3072. (Unless its buffer is full)
03:44 mikemol Also added the rngd instance to inetd, rather than run it with nc6.
03:44 mikemol It'll be good to see where things sit in the morning.
03:50 sorear So no chance of getting prgmr to install a purpose-built TRNG?
04:09 mikemol I wouldn't say that. But I know they're backlogged on a bunch of stuff right now, and this is a decent stopgap in the mean time.
04:09 mikemol I've been giving thought to how a VPS provider would want to handle something like that, too.
04:10 mikemol When you've got hundreds of consumers, you need to find a way to distribute resources fairly among them. You don't want one guy who's piping /dev/random to /dev/null to be able to starve things for everyone else, just like you don't want someone running a bunch of CPU-spinning busyloops to starve CPU from everyone else.
04:11 mwn3d_phone joined #rosettacode
04:11 mikemol You also don't want to install a TRNG accessory per-dom0 (or, worse, per-domU), because that scales into a huge maintenance problem.
04:13 mikemol But you can look at the problem from the perspective of a single VM host box, initially. You've got N VM guests, each of which may consume a stream of bytes at different rates. You want to ensure that they each may get an equal amount in time of scarcity, and as many as they want when there's plenty to go around.
04:13 mikemol I've got an algorithm in mind to resolve that, but I'm almost certainly too tired right now to elucidate it accurately.
04:14 mikemol But, secondly, you've got the same problem if you abstract it out to having one (or more) very good sources of entropy, and N VM *host* machines. You'd likely want to use the same distributive algorithm to pass bytes to the VM hosts.
04:17 mikemol Now, I figure, for getting entropy bytes into the VM guest, you could use a virtualized serial port, and have hrngd consume those bytes, as I have on RC's server. For the dom0, you'd need the entropy bytes to come over the network, and you could put that on an OOB VLAN which has a private IP space.
04:19 sorear mikemol: I think you're overthinking this
04:20 sorear mikemol: the TRNGs that are built in to the newest Intel processors produce 3 billion bits of entropy per second
04:20 sorear mikemol: how fast does a single Web server need entropy?
04:22 sorear the VPS should just provide a guaranteed 20kb/s of entropy to clients as part of the base package, if you want more for scientific computing, cross that bridge when you get there
04:29 mikemol sorear: Those processors are a *long* way aways from being commonplace in data centers.
04:32 mikemol Admittedly, getting even a single one onto a network would mean you'd have a great source of entropy, you're not going to see them replace the majority of operating servers within the next five years.
04:33 sorear I was just thinking about one per data center.
04:33 mikemol Ah. Sure.
04:34 mikemol Then you still have the same entropy distribution problem to worry about. (You still risk hitting a bottleneck somewhere, even if it isn't your origin generator)
04:34 sorear Yes, but entropy allocation is a non-issue.
04:35 sorear Just split it equally to all the clients - there's plenty to go around
04:36 mikemol I'm not sure splitting it explicitly equally is plausible; you'd limit yourself to the speed of the slowest consumer.
04:36 mikemol It's reasonably trivial to split it fairly, which is what I think you mean.
04:36 mikemol And that's pretty much what I was thinking about as the abstract of the source/sink algo.
04:37 sorear Equally, but without flow control.
04:37 sorear Say you have 3 Gbit/s of entropy and 10,000 users
04:38 sorear Each one gets 300 kbit/s of entrop, and drops most of it on the floor because of the 4kbit pool limit
04:38 mikemol At risk of error, I'll try to describe the algo I was thinking of for entropy distribution.
04:38 mikemol Let's say you have 32 consumers, and you have a buffer of 32 bytes per consumer. When a consumer reads a byte, it removes a byte from that buffer.
04:40 mikemol Now, you yourself are a consumer, and every time you have 32 new bytes to distribute, you go through each buffer and check to see if it's full. If it's not, you feed one byte into that buffer. Loop back until either all buffers are full, or until you're out of bytes to distribute.
04:41 mikemol Now, the triggerings of fill events could obviously stand to be improved. And doing things one byte at a time is certainly wasteful. And a buffer of only 64 bytes per consumer is laughable. But you get the idea.
04:44 sorear You've just described "round robin scheduling"
04:44 sorear the problem of allocating entropy is exactly the same as the problem of allocating CPU time
04:45 mikemol Also, in a scenario like this, having flow control helps you prevent flooding your network with too much traffic. You're not going to run a separate wire for entropy feeds, so even on a separate vlan, you're still sharing bandwidth.
04:45 deltree_ joined #rosettacode
04:46 mikemol Good. That means I probably described it reasonably well. I was inspired by what I remembered of how xen vm timesharing worked.
04:48 mikemol I wonder if there are already any generic round-robin stream splitting programs out there. That'd simplify things.
04:51 mikemol Nice. The entropy buffer program is doing a great job. http://rosettacode.org/cdc3/bin/index.c​gi?hostname=prgmr2.rosettacode.org&​plugin=entropy&timespan=3600&ac​tion=show_selection&ok_button=OK
04:51 fedaykin "collection.cgi, Version 3" http://rldn.net/DtkX
04:51 mikemol The entropy is consistently floating between 2048 and 3072 bytes, which are the lower and upper thresholds for its operation. Once it's full, it should float between 2048 and 4096.
04:52 mikemol er. It's already floating between 2048 and 4096.
05:21 ttmrichter joined #rosettacode
05:34 Coderjoe it looks like it should be possible to make the pool larger
05:37 sorear mikemol: do you offhand what the depletion rate is in bits/s?
05:37 sorear very roughly.
05:38 sorear "is it closer to 10^2 or 10^6" levels of roughly
05:38 Coderjoe also, the ioctl does no locking or cache flushing:
05:38 Coderjoe 1149         case RNDGETENTCNT:
05:38 Coderjoe 1150                 /* inherently racy, no point locking */
05:38 Coderjoe 1151                 if (put_user(input_pool.entropy_count, p))
05:38 Coderjoe 1152                         return -EFAULT;
05:38 Coderjoe 1153                 return 0;
05:47 mikemol sorear: I won't know until the entropy buffer fills (It's about halfway there, but I'm hitting the sack imminently) and I stop feeding the server entropy from my home network.
05:48 mikemol But I do know it's trivial to drain the pool of 4096 bits of entropy in less than half a second, just at the rate I type and execute commands like 'cd', 'ls', 'ps', 'grep'...
05:50 mikemol I do need to figure out how to monitor entbuffer's fill level in collectd.
05:52 mikemol The way entbuffer is coded, it *can't* add or remove more than 64 bytes per second to/from the pool. But I only added that limitation because the ioctl return value wasn't updating syncronously, and I was oscillating between completely draining the pool and completely dumping bytes back in.
05:58 Coderjoe hahah
07:03 mischi joined #rosettacode
07:49 saschakb joined #rosettacode
08:01 ttmrichter joined #rosettacode
09:12 mischi joined #rosettacode
09:30 kpreid joined #rosettacode
10:04 ttmrichter joined #rosettacode
10:28 mwn3d_phone joined #rosettacode
12:47 mwn3d_phone1 joined #rosettacode
12:53 mikemol sorear: It's difficult to say how quickly it'll consume entropy. That'll be very dependend on load conditions, which varies by hour and by day, and which frequently spikes.
12:53 mikemol I know very little about the spikes, because they tend to simply pin my entropy level to near 0 for the duration.
12:55 mikemol I should be able to learn more now, as the spikes shouldn't be able to pull the entropy level down past 2048 bits, unless it manages to drain the pool. Meanwhile, I know the refill will occur at roughly 64 bytes per second for the reserve, so I can at least get a minimum value.
12:56 mikemol Whups. I've got two copies of that entbuff program running on RC.
13:12 mikemol I thought of another thing that uses entropy on RC's server. I believe the firewall does stochastic logging; rather than logging every hit 'drop' or 'reject' rule, it rate-limits them.
13:20 eMBee oh, what is the purpose of that? or rather is the purpose anything that needs real entropy for it to work? urandom wouldn't do?
13:21 mikemol I *really* need to write this up in a blog post.
13:22 mikemol urandom uses real entropy, at least for some part of its process. Perhaps it pulls bytes directly out of the pool until the pool's dry. Beyond that, it chews CPU.
13:23 mikemol So having a full entropy pool improves the quality of the random numbers of urandom (in that they're unpredictable), and (I believe) reduces CPU chew by the PRNG.
13:23 Hypftier urandom usually uses a CSPRNG to stretch the actual entropy into output that is hard to predict or deduct the seed from.
13:24 Hypftier at least how I understood it so far (actually, on FreeBSD both random and urandom are identical and use Yarrow).
14:01 slavik1 joined #rosettacode
14:07 robbrit joined #rosettacode
14:26 dagnyscott joined #rosettacode
15:18 mikemol Entropy buffer has been draining steadily at 64B/s for about an hour and a half. It'll probably be empty in an hour and a half.
15:20 mikemol Er. Three hourds.
15:20 mikemol *hours
15:20 mikemol Total thinko.
16:09 mwn3d_phone joined #rosettacode
16:35 mwn3d_phone joined #rosettacode
19:01 mikemol Only 32kB of entropy left in the buffer.
19:02 mikemol I've got a couple 1M buffers filled at home. When the server buffer goes dry, I'll start netcatting those in.
19:13 eMBee so still not enough entropy?
19:19 eMBee how many bits are you sending in from outside?  64b/s? (the refill mentioned earlier)? so  when the buffer drains at 64b/s does that mean it is using 128b/s more entropy than the server provides by itself?
19:20 mikemol eMBee: I just started shoving entropy at the server from home.
19:20 mikemol The buffer described earlier is from a program running on the server which grabs entropy when there's plenty, shoves in it in buffer, and feeds from that buffer when things get thin.
19:20 mikemol It charged over night, and discharged over the day.
19:21 eMBee oh, so it is internal, like a capacitor
19:21 mikemol The way it's coded, it won't charge or discharge at faster than 64B/s.
19:21 mikemol Right
19:22 eMBee unused entropy gets thrown away otherwise?
19:22 mikemol Yeah; the kernel won't store an increasing amount indefinitely; you'd run out of RAM.
19:22 eMBee true
19:23 mikemol The entropy capacitor uses a fixed max buffer size of 1M, preallocated.
19:23 mikemol I need to increase that tonight.
19:24 mikemol So capacitor 1 at home is draining at about 64B/s, capacitor on server is charging at about 64B/s. Somewhere between those two abouts is what's being actively generated and consumed on the two machines involved.
19:24 eMBee that is inthe kernel?
19:25 eMBee i mean the fixed max buffer size of 1M is in the kernel?
19:25 mikemol http://rosettacode.org/cdc3/bin/index.c​gi?hostname=prgmr2.rosettacode.org&​plugin=entropy&timespan=86400&a​ction=show_selection&ok_button=OK
19:25 fedaykin "collection.cgi, Version 3" http://rldn.net/2ix
19:25 opticron you see intel's new tech for entropy generation?
19:25 opticron now all-digital
19:25 mikemol No, kernel's max pool size is 4096 bits. (not bytes)
19:25 eMBee ah
19:25 mikemol Buffer program is one I wrote, adapted from Coderjoe's monitor program.
19:25 mikemol Don't spam that cgi page, btw.
19:26 * eMBee nods
19:26 opticron supposedly can generate good entropy at 1 bit per cycle
19:26 mikemol opticron: Yeah. sorear and I discussed that kinda at length last night. Check the logs for a recap. I've got to get back to work.
19:26 opticron heh
19:27 * eMBee heads out too
19:37 mikemol Home network is feeding bytes to the server at 80-90B/s.
19:58 mwn3d_phone joined #rosettacode
20:08 saschakb joined #rosettacode
20:56 robbrit left #rosettacode
21:30 saschakb joined #rosettacode
21:53 mikemol I swear, I think Google bases some of their page rank on realtime site response speed. The more entropy I pump into the server, the faster the site gets, but then I get more traffic, and entropy goes back down.
22:48 mwn3d_phone Its interesting that it could react that quickly
22:59 mischi joined #rosettacode
23:57 sorear mikemol: how many MB/day of entropy are you feeding the server currently?

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