[ntp:questions] Unexpected ntpd behavior

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


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.


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.
>>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
>>>>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
>>>>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
> ==============================================================================
>>>>*   4 u   55   64  377    0.308  6418.55
>>>> LOCAL(1)        LOCAL(1)        14 l   21   64  377    0.000    0.000
>>>>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.
> 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