On 24 Nov 2017, at 09:20, Hal Murray <hmurray@megapathdsl.net> wrote:

neil.davies@pnsol.com said:
There are a few more issues - the relative drift between the two clocks
can be as high as 200ppm, though typically 50-75ppm is what we observe, but
this drift is monotonic.

200 ppm seems pretty high, but not off scale. If ntpd is running and not
getting confused by long queuing delays, it should correct the drift to well
under 1 ppm. If you turn on loopstats, you can graph it.

I’m saying that is the maximum rate of drift between two clocks even

when they are under NTP control. As you say below the clock rates

are not completely stable they are temperature dependent.

When we did this with the guys at CERN we could

correlate the results with the workload (see below for references).

We’ve got ~1M experiments using this approach across various networks,

the numbers are what we are seeing in practice.

The caveat is that, after a while (i.e several 100s) the clock drift can make

a significant difference (i.e a few ms) in the one-way delay estimation.

If you are blasting the network and adding long queuing delays, ntpd can
easily get confused.

There is another quirk to keep in mind. The temperature coefficient of the
crystal is ballpark of 1 ppm per C. Things can change significantly if an
idle system starts flinging lots of bits around.

Also NTP can make changes at one (or both) ends - they show up as distinct
direction changes in the drift.

I'm not sure what you mean by "direction change". I'd expect a graph of the
time offset vs time to be linear and the slope would have a sharp change if
ntpd changed it's "drift" correction and/or maybe a rounded bend as a system
warmed up.

Don’t forget you are measuring the difference in the rates between two NTP clocks,