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

Richard B. Gilbert rgilbert88 at comcast.net
Fri Oct 19 02:35:08 UTC 2007


Patrick Nolan wrote:
> 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?
>
Yes it is possible.  It's rare but it can happen.

Some Linux systems have known problems with losing timer interrupts! 
During periods of heavy I/O load disk drivers may mask or disable 
interrupts for a little too long a time. . . .  Some Windows systems 
have also been known to exhibit similar behavior.

> 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.

What's the value stored in your drift file?

DON'T use burst!  The burst keyword was intended for situations where 
ntpd has to make a phone call to NIST (or similar service) to get the 
time.  It is NOT suitable for general use over the internet.

Iburst is good.  It gets you a fast startup and then lets your system 
poll the server at normal intervals.

Check the value of a Kernel variable called "HERTZ".  Some Linux systems 
set it to 1000 which is not good for NTP.  If yours is set to 1000 (or 
250) try changing it to 100.

Using a single server is not usually a good idea.  Two servers are the 
worst possible configuration; ntpd has no good way to decide which one 
to believe.  Three are good but four are better.  Try to select servers 
that are close to you in network space (low values of Delay).






More information about the questions mailing list