<div dir="ltr">Please set an account up on <a href="http://thyrsus.com/">thyrsus.com</a> for me.<br><br><br>You can grab SSH keys like so: <br>curl -O <a href="https://github.com/%3Cusername%3E.keys">https://github.com/<username>.keys</a> <br><br><br>So thus get mine at <a href="https://github.com/fallenpegasus.keys">https://github.com/fallenpegasus.keys</a><br><br><br>..m </div><br><div class="gmail_quote"><div dir="ltr">On Mon, May 23, 2016 at 1:54 PM Eric S. Raymond <<a href="mailto:esr@thyrsus.com">esr@thyrsus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Really good plans have happy consequences one didn't foresee. But also<br>
complicating ones.<br>
<br>
Mark encouraged me to work on the Microserver HOWTO as a recruitment<br>
device for future time-service experts and, implicitly, so I would<br>
learn more about how NTP works from the outside. Those were good<br>
reasons.<br>
<br>
Now it's growing another use that Mark may not have foreseen -<br>
benchmarking different ntp.conf setups and measuring comparative<br>
offsets and jitter. For these purposes, having several co-located<br>
machines with identical hardware/software configurations and the<br>
same Internet connectivity is ideal.<br>
<br>
However, this also creates an implicit bottleneck. Hal wants me to<br>
set up a machine with both a HAT and a GR701W and use it to measure<br>
offsets. It's a an excellent idea, but I can't do it in any<br>
predictable amount of time - I'm working as hard as I can just keeping<br>
the project-related backlog in my mailbox from overwhelming me. More<br>
generally, Eric as the only person who can use the test farm is not<br>
going to scale well.<br>
<br>
Accordingly, I'll make logins on the <a href="http://thyrsus.com" rel="noreferrer" target="_blank">thyrsus.com</a> bastion host<br>
available to project developers. The test farm is accessible from<br>
there. I'll make myself available to plug and unplug hardware<br>
on request.<br>
<br>
Current test farm inventory:<br>
<br>
au.local - Pi 2 with blue-wired SKU 424254<br>
cu.local - Pi 2 with Uputronics HAT<br>
fe.local - Pi 3 with Adafruit HAT<br>
<br>
All three have skyview good enough that they pretty much always have<br>
lock except just after power-cycling. GR601-W or GR-701 USB GPSes<br>
can be plugged into any of these on request.<br>
<br>
Soon to arrive:<br>
<br>
* an Odroid C2 (ordered)<br>
<br>
* 8-port Netgear switch because my existing one is run out of ports -<br>
going to dedicate this one to the lab. POE capable because that's<br>
part of the plan for the BeagleBone variant (ordered)<br>
<br>
* an Anker 10-port powered USB hub, because Mark turned out to be<br>
unsurpringly right that el cheapo unpowered hubs aren't stable<br>
enough (ordered)<br>
<br>
* two more Pi 3/Adafruit HAT combinations and a HAT for the Odroid<br>
(not yet ordered, but I know I have to for the ntp.conf comparisons)<br>
<br>
Currently planning for a maximum of 10 test machines and an actual<br>
complement of 7 - 2 Pi2s, 3 Pi3s, an Odroid C2, and a Beaglebone Black.<br>
<br>
Sigh. I've spent years avoiding learning enough about network<br>
management to run a server farm this size. No longer, it seems.<br>
<br>
Funniest possibility: If I need a rack for these systems,<br>
<br>
<a href="https://www.youtube.com/watch?v=Jq5nrHz9I94" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=Jq5nrHz9I94</a><br>
<br>
A functional rack made of legos. That's worth some geekery points<br>
right there.<br>
--<br>
>>esr>><br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@ntpsec.org" target="_blank">devel@ntpsec.org</a><br>
<a href="http://lists.ntpsec.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ntpsec.org/mailman/listinfo/devel</a><br>
</blockquote></div>