[ntp:questions] Ignore one server except in extreme conditions?

Dave Hart davehart at gmail.com
Wed Nov 16 20:05:35 UTC 2011

On Wed, Nov 16, 2011 at 16:14, A C <agcarver+ntp at acarver.net> wrote:
> The PPS is synced almost all the time but the choice of
> clock sources moves around from Internet to NMEA.  In my case the NMEA
> sentences wander but the NMEA clock is always listed as a member of the
> accepted clocks (the "+" indicator) even if its own data is so bad that
> another clock with similar offset and jitter has been labeled an
> outlier/false ticker.
> Note I'm not talking at all about the GPS going away.  I'm talking about the
> NMEA sentence wandering around dragging the clock with it because it's part
> of the overall computed solution.

No, it's not part of the solution.  When you have 'o' in the peers
billboard, the PPS is disciplining the clock alone.  Ignore the rest
of the tally codes as long as the PPS is reachable.

>  By way of example, one of the Internet
> servers in my peer list has an offset of 1.887 and jitter of 0.586 and is
> labeled an outlier.  The NMEA data at that same moment has an offset of
> 21.863 and a jitter of 10.290 and it's labeled as accepted.

This is because NTP doesn't depend solely on offset and jitter.  Root
dispersion plays a factor, and reference clocks (even NMEA) have a 0
root dispersion, while your internet sources have root dispersion
accumulated from the error in your path to them and their path to the
stratum 1 server with the refclock.

> What I'm looking to do is to ignore the NMEA in favor of the Internet clocks
> as long as they are available then fall back to NMEA in case the network
> drops out.
> Before anyone asks, the GPS itself is fine and functioning normally.  It was
> designed as a PPS reference for a fixed location telemetry network over GSM.
>  The PPS portion is very accurate but it sacrifices some stability in the
> NMEA data to achieve the PPS stability (PPS pulse generation is higher
> priority for the CPU than NMEA generation).  Since the telemetry device was
> intended to be in a fixed location it wasn't considered important to have
> very precise NMEA data, only PPS pulses to control timing and slotting.
>  Jitter on the PPS signal is reported by ntpd to be 0.061 ms (ntpd never
> shows jitter numbers lower than this for any source, must be something in
> the floating point calculations) and doesn't wander away from that (I can
> see the same thing on an oscilloscope, the pulse is quite stable).

The reason you see a minimum jitter reported of 0.061 is the precision
of the host clock.  1/16384 is 0.061 msec.  When ntpd starts, it
measures the minimum nonzero difference between subsequent reads of
the system clock.  Your host clock is in the neighborhood of that
value.  ntpd converts the precision to a power of 2 -- yours is coming
up with precision 2 ** -16, and ntpd is using that precision as a
floor to the reported jitter values.  In older versions of ntpd (4.2.4
and earlier), the delay values are also floored at the precision, and
David Taylor and I have seen evidence that delay flooring may be
useful for low-precision host clocks (where ntpd measures precision 2
** -10 or 0.977 msec).

The idea is your host clock is incapable of measuring intervals less
than about 2 ** -16 seconds.  As a result, ntpd "fuzzes" its reads of
the system clock replacing the bits below 2 ** -16 with
normally-distributed random noise.  It also conveys its -16 precision
in its responses to network clients, which factor it into the
calculation of the dispersion attributable to the last NTP hop.  The
response also includes the root dispersion as seen by the server.  The
root dispersion of a client using your server is the root dispersion
your host has calculated plus the peer dispersion your client
calculates factoring in the network delay, your clock precision and
its clock precision.

With a PPS, you should not care about the peer billboard tally codes
dancing once PPS is controlling the clock.  All you need worry about
is ensuring that whether or not you have internet sources, ntpd is
able to determine the seconds numbering so it can use the PPS.  From
your report that the NMEA data is arriving within +/- 50 msec of the
PPS, this should be a slam dunk, and there should be no need to even
use a separately-listed PPS source in ntp.conf -- you should be able
to to use a single NMEA refclock with PPS enabled, and thereby not
need prefer anywhere.  NMEA will number the seconds for its associated

Note the NMEA driver supports two different time fudges.  fudge time1
applies to the PPS signal, fudge time2 to the NMEA end-of-line
timestamp.  time2 compensates both for the systemic delay after the
top of the second before the NMEA sentence being used starts arriving,
and for the time to transmit that sentence through its terminating
CR/LF.  fudge time1 compensates for systemic delay of your system in
timestamping the PPS, including cable delay and debouncing delay in
the UART before it recognizes the state change of CTS, and delay
between the UART asserting the interrupt and the interrupt routine's
execution, and the time to actually read the system clock.

Dave Hart

More information about the questions mailing list