[ntp:questions] ntpd stays synced after loosing gps

Dave Hart davehart at gmail.com
Wed May 11 16:05:24 UTC 2011

On Wed, May 11, 2011 at 15:29 UTC, Nickolay Orekhov <nowhere at mail.ru> wrote:
> Other devices should also have status "unsync" and stop syncing but they
> will continue to sync from unsynced source with stratum 1 infinitely.

No, they will reject the source once its root dispersion ("rootdisp="
in ntpq rv) exceeds the client's "tos maxdist" threshold (in seconds,
default 1.5 in ntp-dev).  That's slightly oversimplified, because the
source's root dispersion is added to the distance from the client's
hop to the source before the comparison:

	 * A distance error for a remote peer occurs if the root
	 * distance is greater than or equal to the distance threshold
	 * plus the increment due to one host poll interval.
	if (!(peer->flags & FLAG_REFCLOCK) && root_distance(peer) >=
	    sys_maxdist + clock_phi * ULOGTOD(peer->hpoll))
		rval |= TEST11;		/* distance exceeded */

You seem to be assuming that the intermediate ntpd should act like a
proxy for its source to its clients.  That's not how ntpd operates --
it disciplines the OS clock into sync with its source(s), and serves
clients using that OS clock, simultaneously providing the maximum
error estimate (in seconds) referred to as the root distance or root
dispersion.  When the intermediate ntpd has lost its sources, it is
still in sync with UTC initially, and only slowly drifts away over
time.  As a result, it is still a useful source, though its usefulness
decays as its root distance increases by 15 usec/sec (15 PPM) to
account for the length of time it's been "freewheeling" since the loss
of all its sources.

You can accelerate the process of clients rejecting the intermediate
ntpd as a source by using "tinker dispersion" (units are PPM or
usec/sec, default 15) on the intermediate ntpd to cause its root
dispersion to grow faster.  The documentation for tinker notes:  "The
default values of these variables have been carefully optimized for a
wide range of network speeds and reliability expectations. Very rarely
is it necessary to change the default values; but, some folks can't
resist twisting the knobs."

Dave Hart

More information about the questions mailing list