[ntp:questions] strange behaviour of ntp peerstats entries.

David L. Mills mills at udel.edu
Sun Feb 3 05:21:45 UTC 2008


You are not accurately describing the ntpd clock filter. An accurate 
desciption would surely help the point you are making.


Unruh wrote:

> Grian Utterback <brian.utterback at sun.com> writes:
>>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.
>>>>Brian Utterback
>>>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.
>>I mis-spoke. It is actually the case that NTP prefers the sample of
>>the eight from any one single source that has the least delay. After
>>the sample is chosen, the samples from all the servers are then
>>subjected to different criteria to determine which will be the final
>>choice. Jitter and stratum both factor in.
> Worse than that . Only if the latest sample is the one with the min delay
> is it chosen Otherwise it is not. You can go for 16 or more samples never
> using any of thembefor one fits the criteion. (actually the samples are
> aged as well-- ie the delay is increased as they get olderbut that seems to
> have little effect.)
> )

More information about the questions mailing list