[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 11.0.0.1 prefer
>>> server 127.127.1.1
>>> fudge 127.127.1.1 stratum 14 refid LCL
>>> driftfile /etc/ntp.drift
>>> pidfile /etc/ntp.pid
>>> disable stats
>>> authenticate no
>>>
>>> Problem is, if time is slow compared to 11.0.0.1 (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
>>> 11.0.0.1.
>>>
>>> Node2# ntpq -p
>>>      remote           refid      st t when poll reach   delay   offset
>>> jitter
>>>
==============================================================================
>>>
>>> *11.0.0.1        192.168.31.253   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