[ntp:questions] Unexpected ntpd behavior

Pete Buelow nospam at putzin.net
Wed Mar 9 18:51:33 UTC 2005

David L. Mills wrote:

> Danny & Co.,
> Don't forget to set the kernel frequency to zero when removing the
> frequency file: ntptime -f 0. Otherwise, you are almost guaranteed an
> evil surge.
> Dave
> Danny Mayer wrote:
>> At 06:55 PM 3/8/2005, Pete Buelow wrote:
>>> Some quick background. Trying to get ntpd running on some IA64
>>> hardware in a
>>> pretty simple environment. Two machines in a pair relationship, the
>>> first machine in the pairing talks to a known good NTP server, the other
>>> talks to
>>> it's paired buddy. OS is Debain Sarge stable, ntp is 4.1.0-8. Ntp is
>>> started with -n -c /path/to/conf -x. Conf is simple, and is below.
>>> server prefer
>>> server
>>> fudge stratum 14 refid LCL
>>> driftfile /etc/ntp.drift
>>> pidfile /etc/ntp.pid
>>> disable stats
>>> authenticate no
>>> Problem is, if time is slow compared to (which works just fine,
>>> it's a timeserver for several hundred lab machines), it will catch up
>>> quite
>>> rapidly (much faster than the 2000s/s rate), and run past. If the time
>>> is ahead of the server, it will just continue ahead. I found a post
>>> below which states that it should then turn around eventually, and head
>>> the other
>>> direction, bouncing like a bungee, but I've never run the test that
>>> long. I
>>> have no idea why this behavior is happening. And it is the same
>>> behavior on
>>> both machines.
>>> A sample ntpq -p output. Clock was set 6 and a half seconds behind
>>> Node2# ntpq -p
>>>      remote           refid      st t when poll reach   delay   offset
>>> jitter
>>> *   4 u   55   64  377    0.308  6418.55
>>> 1.565
>>>  LOCAL(1)        LOCAL(1)        14 l   21   64  377    0.000    0.000
>>> 0.004
>>> Two notes of interest based on other posts I've read
>>> 1. Our tick rate is 1ms instead of 10ms.
>>> 2. On almost all of the test machines, the drift file is populated
>>> with the
>>> value 500. On one it's ~450. According to another poster, that could
>>> be the
>>> source of some issues.
>>> Thoughts? Ideas? I'm assuming right now that it's either a config or a
>>> HW issue. I'm running a test now with this config and command line
>>> options, but am adding "disable kernel" to the config file. Wondering if
>>> that will change the behavior.
>>> Thanks in advance if anyone has any help to offer at all.
>>> --
>>> Pete Buelow
>> Dave has just fixed a problem with drift files being pegged at 500. The
>> fix should be in the latest development build (ntp-dev). You should
>> upgrade in any case since your version of ntpd is rather old. The quick
>> workaround is to remove the drift file before start ntpd.
>> Danny

Thanks for the heads up. Now a question. I've done research into what the
difference is between enabling and disabling the kernel, but does it have
an external impact. Does ntpd use like 10% of the cpu when you add disable
kernel? Or does init get squirrly? It seems like this change is almost
completely benign from a black box point of view, but I really just want to
make sure.

Pete Buelow
replace nospam with putzin if you feel the urge to reply to me directly.

More information about the questions mailing list