Polling interval, Allan Deviation
Hal Murray
hmurray at megapathdsl.net
Wed Jun 26 19:59:59 UTC 2019
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.
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.
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/
--------
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.
--------
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.
--------
That all assumes things are nice in a mathematical sense. Normal
distribution and such.
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.
--
These are my opinions. I hate spam.
More information about the devel
mailing list