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

Maarten Wiltink maarten at kittensandcats.net
Mon Jan 2 09:29:06 UTC 2006

"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

Maarten Wiltink

More information about the questions mailing list