Re: [gpsd-dev] Draft Stratum 1 Microserver HOWTO is up

[Bill Dailey]

Yo Eric!

I have all the parts.  Have done this a number of times.  I should have time to 
do it this weekend.  Just have to dig parts out and start clean. 

Bill

Bill Dailey


> On May 20, 2016, at 9:10 AM, Eric S. Raymond <address@hidden> wrote:
> 
> 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 
>