Raspberry Pi NTP config with fudge factors

[Hal Murray]

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.


-- 
These are my opinions.  I hate spam.