[ntp:questions] failing-over flaky upstream servers

Paul paul-ntp-questions at lookmumnohands.net
Thu Mar 12 17:46:13 UTC 2015

> Drop local driver as that is intended for systems with an external
> clock source providing an accurate disciplined system clock.

That doesn't quite make sense to me.  (To be sure we are talking about
the same thing, I assume you are referring to my "server".)  My use case appears to align with the documented [1]
examples.  I /do/ want it to be the "designated time server to act as
a primary server to provide synchronization to other clients on the
network" [paragraph one], and "the clock of last resort when all other
normal synchronization sources have gone away" [paragraph two] and
"when an external discipline source [like a modem] is available"
[paragraph three].  Well, not a modem, but an external NTP source is
available at least a couple of times a day!  Of course, perhaps I'm
not understanding correctly, so do please tell me again if you think
including the local clock is bad.

> Set up your NMEA clock as prefer peer, and change fudge time to
> centre offset to PPS around zero.

OK - that sounds sensible.  The fudge time in my ntp.conf (fudge time1 0.183106) was indeed set in that way.  From memory,
I configured ntpd to watch the NMEA but not to synchronise, waited for
everything to settle and collected offset readings over a day or so.
The fudge factor is a result of averaging out those samples.  At the
time, I was pretty happy with the result and I'm not sure I could do
better with that driver (driver28).

> If your ref clock generates NMEA sentences, try using the NMEA
> driver, which tries to compensate for sentence timing, instead of
> gpsd SHM.

Ah, ntpd - it's like a game of whack-a-mole - fix one issue, create
another in doing so.  I'm using gpsd because I want to use the NMEA
sentences in other places (hence the use of gpsd).  Now of course, I
could duplicate the serial port - as in create a "virtual serial port"
so that both gpsd and the NMEA driver could get the same serial data.
That, however, is another thing to break and add timing errors.

I also recall some issues where I tried using the NMEA driver
(driver20) but it ended up snarfing the PPS signal.  Or refusing to
play nicely with driver22.  Or something like that.  I've always found
ntpd to be a little on the touchy side.  Unfortunately I can't
remember the exact details on why I ended up with my current setup.

> If PPS still does not work reliably, remove the PPS driver and see
> if the NMEA driver will run with user mode PPS provided by the
> driver.

The PPS /was/ working very reliably... until my prefer peer
disappeared.  The ntpq output probably isn't at all representative of
everything "working"... but it is rather illustrative of why I'm
hoping to improve my configuration.

On the balance, I think I'd prefer to keep the NMEA and the PPS as
separate time sources - if only so I can monitor them separately.

> Let each configuration run for at least six hours and watch
> ntpq -p -c rv -c cv for precision <= -20, stabilizing frequency and
> offset, loopstats drift and offset, and ref clock peerstats offset.

OK, I can do that.

Thanks for your detailed input.  Let me know what you think about the
local clock, if you significantly disagree with my fudge factor on
driver28 and if you think the NMEA driver (20) is significantly better
than the SHM driver (28) for my particular case.

[1] http://doc.ntp.org/4.1.1/driver1.htm


More information about the questions mailing list