[ntp:questions] refclock on Windows graphs
davehart at gmail.com
Tue Mar 17 23:09:43 UTC 2009
On Mar 17, 10:44 pm, Unruh <unruh-s... at physics.ubc.ca> wrote:
> Dave Hart <daveh... at gmail.com> 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.
More information about the questions