Evandro Menezes wrote: [] > I think I found out why NTP couldn't manage. I figured that as it was > stepping every 20min by 0.45s, approximately, it would be the > equivalent of an error of roughly 350PPM, or well within the > capabilities of NTP. > > So I checked out the contents of the drift file: 450PPM. In other > words, NTP was over compensating! I deleted the drift file and fired > up NTP after stopping W32TIME. It's now keeping the time in sync > pretty well: http://img218.imageshack.us/img218/3609/peerstatscf6.png > (never mind the spike, when the system lost network connection). > > The only reason I can think of how NTP got such a huge drift was > during installation. Although the package states that its stopping > W32TIME, somehow it didn't, as I noticed a few hours later. A short > time, yet it seems to have done damage enough. > > Thanks.
Evandro, I've seen this as well, but never been able to tie it down. The drift file goes to a stupidly high value, and the nest solution is to replace it with one with a near-correct value. Why NTP does this I don't know - perhaps after a large step (I saw something like this during the recent leap-second fiasco). Cheers, David _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
