ntpd 1PPS binding considered awful

[Eric S. Raymond]

Heads up, Mark!  Significant technical decision point follows

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > It sounds like this has implications for how I should write the HOWTO
> > recipe.  Are you saying that with refclock 20 the source can get marked as a
> > falseticker if it loses PPS for a while?
> 
> You are missing a critical idea.
> 
> The NMEA and JSON drivers can be setup to use the PPS too.  Both have a mode 
> bit to turn that on/off.
> 
> You can run them in either of two ways.  One way is so that they grab the 
> PPS.  If you look at things with ntpq -p, it should look like a PPS slot with 
> typical PPS numbers.  You can't see how well the serial port is working.  If 
> the PPS stops working, the driver stops using it and ntpq -p will show serial 
> port info.
> 
> Plan B is to turn on/off the mode/fudge bit so they don't use the PPS.  You 
> have to add another driver for the PPS.  That driver needs a way to label the 
> seconds so you have to "prefer" some other driver.  (Yes, it's a krock.)  If 
> your serial port is sane, you can use that.  (Many aren't sane.)
> 
> If you want to use the serial port to label the seconds, you have to get it 
> reasonably close.  That usually requires fudging the time and probably also 
> adjusting mindist (the measure of "sane" above).
> 
> Here is what I'm using on a Pi-3 with an Adafruit HAT:
> 
> server 127.127.20.0 prefer mode 0x010011    # NMEA driver: GPRMC, 9600, stats
> fudge  127.127.20.0 flag1 0            # disable PPS
> fudge  127.127.20.0 time2 0.600        # Fixup offset
> server 127.127.22.0                    # PPS signal, needs prefer
> fudge  127.127.22.0 flag2 0            # Rising edge
> tos mindist 0.100                      # default is 0.001 (1 ms)
> 
> That's a quick hack, not the results of careful tuning.
> 
> The fudge time2 is needed to get the serial port close enough.  The mindist 
> is needed to make the window for "close enough" big enough to work.  100 may 
> not be big enough.

OK, I think I get it now.  My head hurts a lot, but you have succeeded
in conveying how PPS and in-band channels are bound together when using
refclock 20. I still don't quite get what's going on with mindist, but
I remember what Daniel told me about synchronization distance and I have no
doubt of your ability to explain it starting from that.

Hal, I have the utmost respect for your domain knowledge of ntpd; it
is invaluable to this project.  But I think familiarity perversely
limits you in one respect. You correctly describe "prefer" as a crock,
but I think you are are unable to fully grok how ugly and opaque this
recipe is to someone without your intimate knowledge.

Gary is correct, the gpsd+ntpd method is far easier to understand.  Compare
this from the Time Service HOWTO:

-------------------------------------------------------------------
# GPS Serial data reference (NTP0)
server 127.127.28.0
fudge 127.127.28.0 time1 0.9999 refid GPS

# GPS PPS reference (NTP1)
server 127.127.28.1 prefer
fudge 127.127.28.1 refid PPS
-------------------------------------------------------------------

Furthermore, Gary is additionally correct that the split into two
devices makes diagnostics via ntpq easier by not commingling
information from these two sources.  I didn't completely understand
what he was driving at before about that, because translating out of
Garyese is sometimes difficult; I do now, thanks to your example.

The following consequences ensue:

1. The HOWTO recipe will switch to the gpsd+ntpsd method.  It's easier
   for kit-builders to understand.

2. Longer term, I am now convinced that the refclock-configuration
   language of ntpd is too ugly to live.  Tinkering around the edges
   is insufficient; it is a complexity sinkhole that has to die.

Config languages this complex and brittle (I am reminded of
sendmail.cf, though this is admittedly not *quite* so bad) are a
never-ending source of trouble.  They make it difficult for human
beings to hold any generative model of what's going on in their heads.
Configurations get composed with subtle errors and then passed on by
rote.

In the future - I don't know when we'll get there - SHM or some
descendant of it will be ntpd's only local input channel, fed by gpsd
and/or a refclockd using a *much simpler* config language on the
refclockd side.  Actually, my hope is to make refclockd zero-config in
the typical case, the way gpsd is - I can reuse some tricks for that.

Splitting out refclockd has moved upwards on my priority list.  I was
thinking of this as a way of enforcing separation of concerns for
security reasons, but an equally good reason to do it is to actually
force separation of concerns in the config languages.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>