[ntp:questions] refclock on Windows graphs
davehart at gmail.com
Tue Mar 17 21:45:56 UTC 2009
On Mar 17, 9:21 pm, Unruh <unruh-s... at physics.ubc.ca> wrote:
> "David J Taylor" <david-tay... at blueyonder.neither-this-bit.nor-this.co.uk> writes:
> >Dell 4400 hardware sitting in a non-temperature controlled environment -
> >warm in the day, cold at night. I 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 scale
> 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.
> (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.
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
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).
More information about the questions