[ntp:questions] Re: NTP Leap Second on Windows XP

Danny Mayer mayer at ntp.isc.org
Tue Jan 3 03:24:30 UTC 2006


Maarten Wiltink wrote:
> "Jerry Baker" <jerry at novalid.invalid> wrote in message
> news:jh%tf.3767$aB1.462 at trnddc02...
> 
> 
>>Others have reported large drift values. My driftfile has been steady
>>around -70 for over a year, but as soon as the leap second approached,
>>my values pegged at 500. They have been bouncing around since and today
>>have climbed to -59 and still climbing slowly. See
>>http://jerbaker.dhs.org/ntp/
> 
> 
> As soon as it approached? I could understand wild hopping and bouncing
> just after. That is in fact what I saw, and many others too.
> 
> I watched the leap on two Linux hosts, a kernel 2.0.40 and a kernel
> 2.2.26. They were running "ntpq -p -c rv |tee -a timelog" in a tight
> loop, both about three updates per second. Both repeated 23:59:59.
> 
> Then the fun started. As observed by Johan Swenker, also an xs4all
> customer, their four NTP servers started disagreeing. I watched the
> confusion for a bit, went to sleep, got up, watched and listened to
> the Wiener Philharmoniker's New Year's concert, and only around half
> past noon UTC started fixing things. I watched some more wild hopping,
> stepping, bouncing, creaking and groaning, and then disconnected my
> main NTP server from its, still useless, batch of reference servers
> to run free for a while.
> 
> This is a Red Hat box that uses a file /etc/ntp/step-tickers to step
> the time before starting the NTP daemon through the normal SysV init
> scripts. Since stepping was going to do more harm than good, I renamed
> the file. Then I added "disable ntp" to /etc/ntp.conf to let it run
> free. Judging from the "ntpq -p" report, it had by now stepped to some
> 150 ms ahead of real time, so I wrote a new value to the drift file
> and restarted the daemon (/etc/rc.d/init.d/ntpd restart). No step;
> polling four time servers but not adjusting the clock; and the
> frequency correction supplied by the drift file.
> 
> As it turned out, I had guessed wrong. The old drift value was very
> near zero and I had replaced it with 10. So the clock drifted ahead
> even further, at a rate of 10 µs per second. When I came back to look,
> it had (still judging from the "ntpq -p" report) amassed a 900 ms
> difference with my best guess of actual time. Some rough calculation
> of when I intended to look again and how much offset to correct
> until then convinced me to write -27 to the drift file and restart
> the daemon again.
> 
> This host serves five internal nodes and not all of them followed
> very well. One in particular almost reached -128 ms offset. Almost.
> I suppose a 37 PPM instantaneous differential is a lot to ask.
> 
> By the time the offset had been reduced to about -30 ms, the ISP's
> four NTP servers were still not agreeing but I was willing to take
> that chance. I removed the "disable ntp" line from the configuration
> file, restarted the server, and renamed step-tickers back. (In that
> order. I still didn't want the step.) Looking back, I might have also
> reset the drift. After that, things settled down nicely.
> 
> Next time, I'll probably not wait for the confusion to start, and
> turn off clock adjustment and coast preemptively. It's not a problem
> if the network is off by a second, and I now know how to make manual
> adjustments.
> 
> Groetjes,
> Maarten Wiltink
> 
Maarten, I'm not sure why you would do this. First of all step-tickers
is a Red-hat thing for using ntpdate before starting ntpd. You are far
better off just starting ntpd with the -g option and iburst on the
server lines. All this messing with the drift file doesn't really help
you. You should let ntpd do its job and set the drift value.

Danny



More information about the questions mailing list