On Tue, 19 Sep 2006 18:49:48 GMT, Joseph Harvell <[EMAIL PROTECTED]> wrote for the entire planet to see:
>I am doing post-mortem analysis on an NTP related problem in which one >host running ntp-4.1.2 gets in a state where it seems to be making large >step corrections to its local clock. > >When I look at the NTP stats file, I can see that something was terribly >wrong with one or more of the NTP servers this host was using. Sometime >around 18 August, the clocks of NTP servers 192.168.0.1 and 192.168.0.2 >began to gradually diverge reaching a difference of over 800 seconds by >8 September. Compounding this problem, the peerstats also shows one of >the NTP servers periodically (period of ~900s) being detected as >unreachable over the whole duration. The other NTP server had a few >sporadic incidences of being unreachable. <snip> >How can I avoid the large clock stepping in this scenario? Is it >related to the "prefer" keyword used for 192.168.0.1? Hi Joe - I have had a couple of bad experiences with the "prefer" keyword. I would not recommend using it at all. In my case using PREFER originally seemed to reduced clock hopping and improve the quality of our time. Then the reference clock that was PREFERed went out of kilter (relating to a leap-second bug) and because of PREFER my Stratum 1 NTPD stayed with the bad clock. I had a stratum 2 that PREFERed that local S1 so it stayed with the bad S1 server. All told, about half of my ntpd servers and clients synced on the incorrect time (~1 sec off) until the PREFERs were removed, where upon the insane clocks were ignored and the ntpd processes reconverged. If you are having issues of time steps and unreachable servers, PREFER would likely cause those problems to magnify and spread. - Eric _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
