[ntp:questions] Re: 2 NTP Servers with diverging clocks and how to avoid stepping backwards in time (repost)

Eric nospam-01 at jensenresearch.com
Wed Sep 20 20:29:08 UTC 2006


On Tue, 19 Sep 2006 18:49:48 GMT, Joseph Harvell <jharvell at dogpad.net>
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


  




More information about the questions mailing list