[ntp:questions] Can a clock drift be too big for ntpd?

David Woolley david at ex.djwhome.demon.co.uk.invalid
Sat Oct 20 10:25:28 UTC 2007

In article <ywn91wbqaa39.fsf at ntp1.isc.org>,
Harlan Stenn <stenn at ntp.org> wrote:

>>> In article <slrnfhg0ap.vl7.pln at glast2.Stanford.EDU>, Patrick Nolan <pln at glast2.Stanford.EDU> writes:

Patrick> 6-10 minutes per day, well over the 500 ppm limit.

> As others have noted, ntpd cannot help in this situation, if it cannot be

If it is systematic, it can be pre-corrected using tickadj; however, a 
static error this large due to the clock hardware would suggest the need
for a new motherboard, and one due to lost interrupts will vary with 
system loading, and, at best, will result in the severe hunting of the
time, and may result in the difference between quiet and busy period 
exceeding the ~900 ppm that you can cover by pre-compensating for the 
centre of the error band.  If the uncertainty in the daily, open loop,
drift really is 10 - 6 = 4 minutes, you almost certainly do have a 
lost interrupts problem and pre-compensating will not be enough.

> Yes, but be sure to rule out hardware *and* OS issues first.  See above.

A bad clock frequency is a hardware issue!

> Patrick> ntpq -p says this: remote refid st t when poll reach delay offset
> Patrick> jitter
> Patrick> ==============================================================================
> Patrick> grandfather.Sta .GPS.  1 u 49 64 375 0.243 2833.49 1139.84

> grandfather is not sync'd - you will not be able to sync to it while it is
> like this.

grandfather is synced (stratum 1).  It has lost its * because the
offset is more than 128ms and ntpd is in the reconfirming offset state.
It does seem to have lost one query, suggesting that, especially if
it is on the LAN, the network is overloaded (wide area networks are
designed to lose the occasional packet).  However the delay is very low,
so it is unlikely that even severe network congestion will result in
clock steps.  (Alternatively, you just lost a large number of consecutive
clock interrupts, and the real delay is much larger - but then the lost
interrupts would be the primary issue.)

More information about the questions mailing list