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