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

Steve Kostecke kostecke at ntp.org
Sat Oct 20 02:57:47 UTC 2007

On 2007-10-19, Patrick Nolan <pln at glast2.Stanford.EDU> wrote:
> On 2007-10-19, Richard B. Gilbert <rgilbert88 at comcast.net> wrote:
>> What's the value stored in your drift file?
> Currently it's 74.080.  This morning it started out around 30.

That's an excessive change.

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

'burst' is an 8x multiplier; it causes ntpd to send a burst of 8 packets
at evey poll interval instead of the usual single packet. That's all.

In addition to the previously mentioned use during modem connections,
'burst' is useful in situations where one must overcome packet loss

The problem with using burst against someone else's time server is that
you are greatly increasing the load your ntpd presents to that server.

> Without burst, it just drifts freely.

This would suggest that there may be connectivity issues. Perhaps faulty
hardware or, perhaps, interrupt sharing between the NIC and another busy
portion of the system (e.g. a hardrive).

> Oct 19 13:37:23 client ntpd[12595]: time reset +13.151972 s
> Oct 19 13:55:58 client ntpd[12595]: time reset +8.779090 s
> Oct 19 14:08:09 client ntpd[12595]: time reset +8.712040 s
> Oct 19 14:28:21 client ntpd[12595]: time reset +11.494533 s
> Oct 19 14:44:53 client ntpd[12595]: time reset +9.450835 s

The rate of change is fairly consistant. It ranges from 7.8 to 11.9
ms/sec. This is actually a good sign.

Since the rate of change is fairly consistent (and is always in the same
direction), it's possible that adjusting the tick make be the solution.

You may want to review a larger log to be sure.

>> 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.
> More ignorance on my part.  Where would I look for this?  I searched 
> the kernel source code and didn't find it.

Answered in another article.

> Here's another issue.  I just learned about the distinction between
> the kernel clock and the hardware (TOY) clock.  I have tried running
> hwclock from time to time, comparing it to my WWV-controlled wall
> clock.  It never seems to be more than 1 or 2 seconds off.  Is there
> any way to exploit this?

The hardware clock in a PC is made of exceedingly cheap components. A
common quartz wristwatch is a better clock.

Steve Kostecke <kostecke at ntp.org>
NTP Public Services Project - http://support.ntp.org/

More information about the questions mailing list