[ntp:questions] refclock on Windows graphs
unruh-spam at physics.ubc.ca
Wed Mar 18 01:00:29 UTC 2009
Dave Hart <davehart at gmail.com> writes:
>> >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 mos=
>> situations, however, it simply results in discarding good data.) Admitted=
>> 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?
It does not. It has a variety of options. You can set it up to discard all
packets whose round trip time is X msec, or whose roundtrip time is a
fraction F larger than the minimum roundtrip time. In general it tries to
use all of the data it can. It does what amounts to a running estimation of
the minimum Allan variance, decreasing the averaging time if the drift rate
exceeds the fluctuations. It also remembers the past X measurements, and
uses them to estimate the current offset and drift (correcting them for any
changes that chrony itself produces in the offset and drift) I is
aggressive in trying to eliminate the offset, using larger frequency shifts
than 500PPM for short time periods to do so (Ie, it uses both the tickadj
and the freq adjust of adjtimex).
>> 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.
As you can guess, I run Linux exclusively so cannot help with any Windows
More information about the questions