"Jerry Baker" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> 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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
