[ntp:questions] Unexpected ntpd behavior

David L. Mills mills at udel.edu
Fri Mar 11 02:31:50 UTC 2005


Pete,

Think of the generic kernel clock as a hamster running inside a wheel. 
Once in a while somebody like NTP gives it a nudge one way or another. 
If you disable kernel, NTP doesn't do the nudge.

Dave

Pete Buelow wrote:

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



More information about the questions mailing list