[ntp:questions] refclock on Windows graphs
unruh-spam at physics.ubc.ca
Tue Mar 17 22:44:10 UTC 2009
Dave Hart <davehart at gmail.com> writes:
>On Mar 17, 9:21=A0pm, Unruh <unruh-s... at physics.ubc.ca> wrote:
>> "David J Taylor" <david-tay... at blueyonder.neither-this-bit.nor-this.co.uk=
>> >Dell 4400 hardware sitting in a non-temperature controlled environment -
>> >warm in the day, cold at night. =A0I would happily accept five times the
>> >jitter for a fifth of the offset!
>> Maybe when someone finally put refclock support into chrony you will have
>> your wish. It sounds like your temp changes causing rate changes on a sca=
>> that ntp cannot properly cope with.
>You really should glance at the 3 graphs he pointed to:
>There's no need to speculate, you can see it all.
And I change nothing in what I said. It agrees with exactly what he said.
(except no temperature plot, so I have no idea whther that change is
because of 1C temp variation or a 50C variation. Note that the latter is
possible if the computer is heavily used during the day running the
internal temp up to 70C and it cools at night.
It might be useful to also plot the itnernal temp from one of the onboard
>> (ntp is terrible at coping with
>> changes-- a purposeful design decision by Mills)
>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.
The minimum delay clock filter I am afraid I am not as enamoured of it as
you are. In some circumstances it is useful, in many it is terrible.
>There is a striking similarity between the minimum delay clock filter
>and my revamped interpolation code for Windows. 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. But we have
seen time and again that the cost of the simplicity (slow response)
is something people really do not want to bear.
>most accurate estimate of the remote clock. The new interpolation
>scheme converts a counter to a timestamp by selecting from a history
>of recent correlated OS time & counter values the one which calculates
>the latest timestamp, based on the observation that all error
>associated with the counter having been sampled some indeterminate
>amount of time after the OS time advanced a tick (or 10-15ms) is
>negative (resulting in erroneously earlier timestamps).
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.
More information about the questions