On Mar 17, 10:44 pm, Unruh <[email protected]> wrote: > Dave Hart <[email protected]> writes: > >That's one view. I look at ntpd as terribly suspicious of change ;) > >The slow response is beneficial if you are relying on remote NTP > >servers and the surviving sources change over time with different > >apparent average offsets, much of the difference being driven by > >asymmetric delays. The chief contributor to the slower response for > >WAN scenarios is the minimum delay clock filter, which I wouldn't give > >up for the world. It's brilliant. > > Since the world of computer clock crystals is known to change to be > too suspicious of change is as bad as accepting it to readily.
Agreed, and temperature compensation (whether based on a static profile or a temperature probe) is intriugiing. > >The minimum delay > >clock filter selects the shortest roundtrip delay of the last eight, > >based on the observation the least-delayed exchange results in the > > And if the variation in the delays is less than the jitter, this simply > results in throwing away most of your measurements. It is a terrible > experimental design procedure that throws away perfectly good data. > In some situations yes, this is a good thing to do, in most it is not. > (Maybe in Mills's "telegraph line in Malaysia" it was a good idea. In most > situations, however, it simply results in discarding good data.) Admittedly > trying to decide if the data is good or not would result in more complex > code, and for many cases, that complexity would be overkill. It's true that sometimes ntpd disbelieves a sample because its delay is higher than an older sample, even if the newer sample is a better reflection of the remote clock (such as when one of the clocks is slewing noticably). The response is delayed until a newer sample has a lower delay or the older low delay sample is pushed out of the eight- deep sample history. But in my experience you don't have to be on a primitive connection to benefit from the filter's mitigation of error introduced by variable network delay. I see it working marvelously on a lightly-used gigabit ethernet with delays between 150-250us. I'm guessing from your response that chrony doesn't use a minimum delay clock filter 8 deep, can you verify? > I will leave to you the decision as to the cost-benefit ratio of this > strategy to try to overcome the inherent limitations of Windows timing. And I would love to leave more of the evaluation to others but so far only a few brave souls have been downloading binaries or source. David J Taylor and Martin Burnicki have both discussed their results favorably. I can only hope the silence of the majority of the lurking downloaders is a good sign as I await any further reports. Cheers, Dave Hart _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
