[ntp:questions] failing-over flaky upstream servers

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Thu Mar 12 15:46:39 UTC 2015


On 2015-03-12 06:36, Paul wrote:
> I would like my ntpd to continue serving time, gracefully choosing
> from the "best" available upstream servers.  (I'll state here at the
> outset that I'm not serving time outside my local network.)
>
> I have the following time sources available:
>
>    1. NTP servers on the Internet.  Internet is mostly available.
>       Individual upstream servers may occasionally disappear
>       temporarily or permanently.
>
>    2. NMEA sentences (via gpsd).  Excellent availability but terrible
>       accuracy (due to the non-deterministic nature of sentence
>       length and non-guaranteed trigger point from second epoch).
>
>    3. PPS signal derived from GPS.  Excellent accuracy, but only
>       available say 90% of the day due to satellite visibility.
>
> How do I best configure ntpd to get the best available time under
> changing circumstances?  I also like to be able to "unplug the
> Internet" without ntpd getting upset.  If I recall correctly, in order
> for PPS to function it needs a "prefer" peer, and I am unsure what the
> best selection is.
>
> In theory; once ntpd is running; given my available time sources and
> provided the clock doesn't drift more than 500ms, it should be able to
> keep excellent time based on the local clock and PPS.  The question
> then becomes how best to configure ntpd to reflect this.
>
> This is my current ntp.conf (at least a redacted extract thereof):
>
> server internet0 iburst
> server internet1 iburst prefer
> server internet2 iburst
> server internet3 iburst
> server internet4 iburst
>
> # pps-gpio on /dev/pps0
> server 127.127.22.0 minpoll 4 maxpoll 4
> fudge 127.127.22.0 refid PPS
> # enable kernel PLL/FLL clock discipline
> fudge 127.127.22.0 flag3 1
>
> # Undisciplined Local Clock
> server 127.127.1.0
>
> # SHM driver accessing NMEA via GPSD
> server 127.127.28.0
> fudge 127.127.28.0 refid NMEA
> # mean avg offset when 377 reached
> fudge 127.127.28.0 time1 0.183106
>
> Here is the current 'ntpq -p' results.  As you will note, my prefer
> peer died some time ago, and now the PPS is being ignored.
>
>      remote      refid st t when poll reach   delay   offset  jitter
> ===================================================================
> -internet0   upstream  3 u   58   64  377   16.560   -6.112   1.680
>   internet1   upstream 16 u  74d 1024    0    0.000    0.000   0.000
> -internet2   upstream  4 u   36   64  377   25.559   -8.380   5.171
> +internet3   upstream  2 u   14   64  377   25.963   -4.732   1.422
> +internet4   upstream  3 u   56   64  377   13.535   -5.390   2.924
> xPPS(0)      .PPS.     0 l    7   16  377    0.000   -2.482   0.040
>   LOCAL(0)    .LOCL.    5 l  94d   64    0    0.000    0.000   0.000
> *SHM(0)      .NMEA.    0 l   46   64  377    0.000   -0.544   1.633
>
> Any thoughts?  How would you go about configuring ntpd for these
> clocks?

Drop local driver as that is intended for systems with an external
clock source providing an accurate disciplined system clock.
Set up your NMEA clock as prefer peer, and change fudge time to
centre offset to PPS around zero.
If your ref clock generates NMEA sentences, try using the NMEA driver,
which tries to compensate for sentence timing, instead of gpsd SHM.
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.
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.
On my Acer desktop Windows 7 64 bit system with invariant TSC and
drift ~0.9ppm, user mode PPS manages to keep within 60us max jitter.
-- 
Take care. Thanks, Brian Inglis


More information about the questions mailing list