Polling interval, Allan Deviation

[Achim Gratz]

Hal Murray via devel writes:
> Consider something like the collection of samples from a PPS.  Assume ntpd is 
> not running so the system clock is not bouncing around.
>
> There is some noise with each sample.  If you collect several samples, you can 
> average them to get a better number.  You probably want 2 numbers rather than 
> 1, a straight line fit, time offset and frequency offset, rather than just a 
> simple average time offset.

If you consult the RADclock papers you'll find a good discussion of
this.  The gist is that there is a systematic bias (i.e. interrupt
latency) that doesn't average out and the statistics have a long tail on
the large delay side (i.e. mode is lower than median which is lower than
the average).  You're also prone to find multiple modes in the data
(i.e. a "lumpy" tail).  Properly censored to the lowest mode you can
however determine the frequency offset with good fidelity.

> But if you average over too many samples, the temperature will change or the 
> crystal on your system will drift with age.  There is a sweet spot in the 
> middle between too few samples and too many.

Even if the temperature was stable, the statistics for the phase do not
converge, i.e. whatever slope you fit the deviation of data from the
fitted line can become arbitrarily large as you extend your collection
to infinity.

> The graph of goodness vs averaging time is called the Allan Deviation.
>   https://en.wikipedia.org/wiki/Allan_variance
>
> http://www.leapsecond.com/pages/adev/adev-why.htm
> http://www.leapsecond.com/pages/adev-avg/

Allan deviation uses the fact that the time difference statistics do
converge in a wide array of conditions.

> You can stand on your head, or turn things inside out, or ...  If the PC clock 
> is "good", you can collect data on a less good external time source.  If your 
> external time source is good, you can collect data on your PC clock.

If you only have these two and know which one is better, then yes.  The
way this works is that once you designate one clock as the reference you
will attribute all errors to the other.  If you have a third clock (or
more) you can actually figure out whether that assumption is correct and
in some circumstances attribute the error back to the correct source.
Practically speaking there will always be a portion of the error that
you cannot separate and have to assign arbitrarily or based on prior
knowledge of the quality of your clocks.

> Another way of looking at this problem is that you want your PLL to filter out 
> the high frequency noise, but let the low frequency drift through so the PLL 
> can fix it.  There is a sweet spot on the filter bandwidth or time constant.  
> That's at the bottom of the V of the ADEV graph.

Not all ADEV graphs have a V in them.  The better description, IMHO, is
to say that the ADEV of the local oscillator in the PLL must be lower
than the clock it's supposed to clean up below some tau and the PLL time
constant must match that tau.  That way, the behaviour above the
critical point is governed by the clock (GPS or whatever else is
providing the PPS) and below it's governed by the locasl oscillator (an
XO … OCXO).  Again, if you look up the RADclock papers you'll find that
for typical PC hardware you're looking at a range of several ten to
several hundred seconds.

> That all assumes things are nice in a mathematical sense.   Normal 
> distribution and such.

There's no normal distribution in sight, otherwise we'd not need Allen
Deviation to describe things.

> If you are working with a PC, the lab temperature can change or the PC 
> temperature can change when the CPU does some work.  Optimizing the polling 
> interval for good conditions may (will?) not work well when conditions are not 
> nice.

As long as you err on the short tau side there is not much you lose via
thermal pulling unless you have truly pathological conditions.  PC
crystal oscillators are pretty noisy to begin with.  For NTP w/o
hardware timestamping at least, the network jitter is large enough that
any improvements you make beyond a certain point won't show up for the
clients of that server.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs