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

Patrick Nolan pln at glast2.Stanford.EDU
Fri Oct 19 00:59:05 UTC 2007


I'm having trouble with one linux client out of a group.
It seems as if ntpd can't keep its clock syncronized.  It's
drifting about 6-10 minutes per day, well over the 500 ppm limit.

After reading some of the posts on this newsgroup, I have come
to realize that debugging ntp problems can be quite complex.
Before I launch into a detailed search, I would like to clarify
one question.  Is it possible for the clock frequency to be so 
far off that ntpd just can't get it under control?
 
I have stripped my ntp.conf to the minimum, just one server
line and a drift file.  The log entries look like this:

Oct 18 17:23:32 client ntpd[30920]: synchronized to 171.64.7.87, stratum 1
Oct 18 17:27:48 client ntpd[30920]: no servers reachable
Oct 18 17:29:06 client ntpd[30920]: synchronized to 171.64.7.87, stratum 1
Oct 18 17:29:16 client ntpd[30920]: time reset +10.678548 s
Oct 18 17:29:58 client ntpd[30920]: synchronized to 171.64.7.87, stratum 1
Oct 18 17:31:59 client ntpd[30920]: no servers reachable

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

For a while there was a * in the first column, but it went away.
Did I mention that there are several other clients with no problems at all?
ntpd 4.2.2 is running with -g, burst, and iburst.

So, does this look like a hardware problem?
If not, I'll have to dig into networking and details of the configuration.




More information about the questions mailing list