Unrug, You are not accurately describing the ntpd clock filter. An accurate desciption would surely help the point you are making.
Davde Unruh wrote: > Grian Utterback <[EMAIL PROTECTED]> 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 >>>>probably >>>>more typical than your set-up. >>>> >>>>Brian Utterback >>> >>>Brian, >>> >>>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. >>> >>>Cheers, >>>David >>> >>> > > >>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.) > ) _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions