[ntp:questions] strange behaviour of ntp peerstats entries.
David L. Mills
mills at udel.edu
Wed Jan 30 20:23:05 UTC 2008
There seems to be widespread misunderstanding about how ntpd ranks the
survivors. The sort ranks the survivors first by stratum and then by
what the spec calls root distance within the same stratum. Root distance
is calculated as one-half the root roundtrip delay plus the root
dispersion plus the jitter. This is the maximum error of the client
relative to the primary source. Note that jitter usually plays only a
small part in the calculation, unless there is some timequake or other
dramtic event at the server.
Sometimes oneor more of these quantities changes dramatically due to a
timequake or maybe the server has lost all its sources for awhile. So,
before you conclude ntpd is doing something evil, check each of the
contributions to root distance.
The result of the sort is usually the first entry on the list, but even
that can be temporarily displaced by the anti-clockhop algorithm. Other
than this wiggle, it can be truthfully said that the algorithm selects
the servers at the lowest stratum and from among those at that stratum
the candidate with the lowest maximum error.
You may argue this is not your goal; you might want the lowest jitter
and disregard all else. Be advised the criteria needs to be stable and
not change a lot very fast; otherwise, clockhopping can easily become
David J Taylor wrote:
> Brian Utterback wrote:
>>Which is why NTP prefers the source with the smallest delay. The
>>system I am using has servers whose delays are 51ms to 94. I can't
>>find any closer. On my company LAN, the delays range from 16ms to
>>87ms. The offsets of all these servers agree to within 9ms. Sure, I
>>am not going to get sub-millisecond from that, but I think it is
>>more typical than your set-up.
> I know this is supposed to happen, but I recall seeing behaviour some time
> ago where a server with a little more jitter and much more delay was
> preferred, almost as if it was the jitter/offset which was the measure
> rather than offset itself. I ended up adding a "prefer" qualifier.
More information about the questions