I now have, at
http://www.catb.org/esr/faqs/stratum-1-microserver-howto/
a recipe that turns a Raspberry Pi and any of three GPS hats into a
Stratum 1 server in about 20 minutes of work. Most of the steps can be
done by calling different modes of a "clockmaker" script, rather than
typing lots of command sequences.
(Special thanks to Frank Nicholas and Anthony Stirk, whose donations
of equipment made it possible for me to build a proper test farm.)
There are several test points in the instruction sequence, each
accompanied by both descriptions of correct behavior *and* material on
how to recover if what the user sees is not what was was expected.
These have two purposes, one obvious and one subtle. The obvious
purpose is to make it easier to fix missteps. The subtle purpose is to
help the reader develop a generative model of what is going on.
Before I call this thing 1.0 and publicly announce it, I'd like someone
other than me (ideally several someones) to run through the procedure
and report any errors and omissions they find.
While this might seem like a diversion from the main thrust of NTPsec work,
Mark blessed it because he has a notion of broadcasting it to hackerspaces
and recruiting the next generation of time-service experts from people who
pick it up. Criticize accordingly; my goal is for the text to be accessible
to tinkerers who are only casually familiar with a Unix command prompt.
Another effect of this exercise, possibly also intended by Mark, is
that it has remedied some of my deficiency in understanding of the code.
Previously my grasp of it has been from inside to out - from the outside
in I could barely even read an ntpq -p display. Things have improved
a little; I'm nowhere near the expertise of someone like (say) Gary Miller,
but now I'm no longer completely lost. So that's good for the project.
In order to get this thing to a place where I could ship it, I've been
ducking controversy over what should go in the ntp.conf file. Presently
I'm using a configuration that uses a timeservice build of gpsd to get
GPS samples and feeds them via SHM. I did it this way because I think
it creates better test points and a configuration that has the fewest
possible headache-inducing weirdnesses.
Now that I *have* a basic configuration that works, I'd like to see
proposals for more advanced configurations - with offset fudges, using
refclocks 20 and 22, that sort of thing. My intention is to open a new
section under "Advanced topics" for these. With luck, laying them
out side-by-side will somewhat reduce the opacity of the ntp.conf
configuration language.
Another purpose of collecting alternative configurations is so I can
benchmark the KERNEL_PLL code. The possibility has been raised that
due to faster processors and better schedulers it is obsolete -
something best tested on a low-end processor like a RasPi. If it is,
we want to know it and be able to document that so we can *remove* the
KERNEL_PLL code. This is one of the few possible simplification
attacks we have on the nasty hairball at the center of the codebase.
(For exactly this reason I've ordered another Pi 3/Adafruit HAT combo -
I want to be able to collect stats on PLL and non-PLL configurations
over the same period.)
So, you domain experts out there - Hal Murray, Frank Nicholas, Gary
Miller, Anthony Stirk, David Taylor, anyone else - feel free to send me
your configurations. Each should include some supporting material -
most obviously, an explanation of why you did it that way. Any special
switches or options should be explained with care.
(I'd also like to assemble a table of fudge factors for the ublox-6,
ublox-8, and MTK3301 that can be applied to the base configuration.)
Some open issues:
* I have yet to actually see 1PPS from the SKU 424254. Phil, you and
I need to put a scope on this thing and check that it's shipping
on GPIO 5 the way it's supposed to.
* I couldn't use the latest Raspbian images because they screw up the
mode of the UART pins at boot time. The third-party hack required
to undo this (link in the HOWTO) didn't work for me. Can anyone else
make it work? What am I missing here?
* Extending coverage to the Odroid C2 (Mark's request). This will be
near-term; I've ordered one.
* Extending coverage to the BeagleBone. Longer-term. Will probably
require significant refactoring of the HOWTO.
Any help with these would be much appreciated.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
To stay young requires the unceasing cultivation of the ability to
unlearn old falsehoods.
-- Lazarus Long
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
