[ntp:questions] Re: NTP Clock Hopping Question

David L. Mills mills at udel.edu
Thu Sep 25 15:53:01 UTC 2003


Ouk,

Clockhoping in and of itself is not a bad thing, as long as the accuracy
is not significantly degraded. The mitigation algorithms select the pick
of the litter and find the alpha kitten ("*" tally), which ordinarily
has the lowest synchronization distance. Then, the actual clock update
is a weighted average of that pick. In normal operation as the result of
ambient jitter among servers of nearly the same distance, the alpha
kitten may change from time to time, but the actual clock update may be
only slightly affected.

Having said that, please note NTPv4 includes an anticlockhop algorithm
that keeps a running exponential average of distance for each server and
a hysteresis threshold that discourages hopping unless truly
significant. This turns out to be necessary for manycasting, where the
overhead of a server reselect can be significant. This consideration is
also be applicable to the pool scheme if on-fly reselect is implemented.

The VMS port of NTP is very, very old. You get what you get what you
get.

Dave

Ouk wrote:
> 
> Hi,
> 
> I've an OpenVMS system (OpenVMS 7.3, TCPIP Services 5.1 implementing
> NTP V3) that I want to synchronise to a collection of corporate
> Stratum-2 NTP time servers.
> 
> I've the following server/peer entries in my configuration file:
> 
> server 10.3.1.11
> server 10.1.1.11
> server 10.4.1.11
> server 10.3.2.11
> peer NODE2
> 
> The results of an NTPQ are:
> 
> $ ntpq -p
> 
>      remote           refid      st t when poll reach   delay   offset
>    disp
> ==============================================================================
> +10.3.1.11       10.1.3.4         2 u   63   64  377     0.89    1.081
>    0.70
> -10.1.1.11       10.2.1.2         2 u    6   64  377     0.87   -0.520
>    0.90
> +10.4.1.11       10.1.3.4         2 u   18   64  377     8.79    0.796
>    1.37
> *10.3.2.11       10.2.1.2         2 u   14   64  377     0.00   -0.379
>    1.33
>  LOCAL(0)        LOCAL(0)        10 l   39   64  377     0.00    0.000
>   10.48
> +NODE2           10.1.3.2         3 u   40   64  376    -0.27   -1.071
>    1.79
> 
> NODE2 is another OpenVMS Alpha with a similar set-up although it looks
> at a different set of four Stratum-2 servers. The fudged local clock
> is there for other nodes in the local LAN to use once I've stabilised
> this set-up.
> 
> I'm seeing (I believe) an excessive amount of clock hopping (every 2-3
> minutes or so) between the NTP servers. For example, in the last hour:
> 
> 23 Sep 16:53:17  synchronized to 10.1.1.11, stratum=2
> 23 Sep 16:53:43  synchronized to 10.3.2.11, stratum=2
> 23 Sep 16:57:54  synchronized to 10.1.1.11, stratum=2
> 23 Sep 16:58:00  synchronized to 10.3.2.11, stratum=2
> 23 Sep 17:05:01  synchronized to 10.1.1.11, stratum=2
> 23 Sep 17:11:36  synchronized to 10.3.2.11, stratum=2
> 23 Sep 17:19:59  synchronized to 10.1.1.11, stratum=2
> 23 Sep 17:21:44  Previous time adjustment incomplete; residual
> 0.000001 sec
> 23 Sep 17:21:51  synchronized to 10.3.2.11, stratum=2
> 23 Sep 17:24:39  synchronized to 10.1.1.11, stratum=2
> 23 Sep 17:24:56  synchronized to 10.3.2.11, stratum=2
> 23 Sep 17:27:53  synchronized to 10.1.1.11, stratum=2
> 23 Sep 17:35:13  synchronized to 10.3.2.11, stratum=2
> 23 Sep 17:37:10  synchronized to 10.1.1.11, stratum=2
> 23 Sep 17:41:09  offset: 0.000426 sec  freq: 1.850 ppm  poll: 64 sec
> 23 Sep 17:44:52  synchronized to 10.3.1.11, stratum=2
> 23 Sep 17:45:47  synchronized to 10.3.2.11, stratum=2
> 23 Sep 17:46:00  synchronized to 10.1.1.11, stratum=2
> 23 Sep 17:47:38  synchronized to 10.3.2.11, stratum=2
> 23 Sep 17:47:44  synchronized to 10.4.1.11, stratum=2
> 23 Sep 17:52:44  synchronized to 10.3.2.11, stratum=2
> 23 Sep 17:52:59  synchronized to 10.1.1.11, stratum=2
> 
> I think the clock-hopping may be a result of the corporate server
> set-up, which is not under my control - The 'refid' of the Stratum-2
> servers appears to change quite frequently.
> 
> I'm thinking of adding a 'prefer' keyword to one of the server
> configuration lines in order to stop this - is this a good idea? Or,
> have I made some awful configuration faux-pas that's causing these
> results?
> 
> Ouk.



More information about the questions mailing list