David Lord wrote:
Solutions that measure the temperature require calibration
for the individual crystal as with the cheap crystals used
the drift per deg C can be either positive or negative and
also depending on "cut" of the crystal can follow a
parabolic or "lazy S" curve.
The only reasonable way to handle this problem IMHO is to have a big
history table:
For each adjustment period, log the temperature and the current best
estimate clock frequency delta (i.e. offset from average drift rate).
This could be in the form of full statistics, or (much simpler!) an
exponential decay for each possible temperature reading. The latter just
needs a couple of multiplications and an add for each update.
The entire table starts by being initialized to zero, then it should be
saved away once a day or so. When restarting you can load the previous
history.
The alternative of fitting a simple heater with temperature
control to the crystal seemed to be more effective and with
pps ntp source the offset was < 300n.
Nice.
This does require you to open the box though, while a sw only solution
could even be used on a rack full of blade servers. :-)
Terje
--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
