Re: [chrony-dev] frequency fallback when running unsynchronised

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-dev Archives ]


On Fri, 9 Apr 2010, Miroslav Lichvar wrote:

On Fri, Apr 09, 2010 at 07:50:58AM -0700, Bill Unruh wrote:
On Fri, 9 Apr 2010, Miroslav Lichvar wrote:
The attached patch implements a series of exponential moving averages
of absolute clock frequencies that are calculated over exponentially
increasing intervals. When chronyd is unsynchronised for some
specified interval, it will start switching the clock frequency to the
long-term averages.

Interesting idea. The place that really really needs this most is the rtc.
at present, the system saves the instantaneous rtc rate offset to use to
correct the rtc next time it is turned on. But that rate is an "instantaneous
rate", while typically the computer is left off for a long period.

There is a very similar problem with driftfile. Maybe we could store
in the file also the averages with timestamps and on start chrony
would choose the best value depending on for how long it wasn't
running.

Duplicating this for rtc shouldn't be very hard.

(of course
the bigger problem is that when the computer is off, the rtc is cold, and the
cold rate is probably significantly different from the hot, but I have no idea
how to get around that problem!)

Perhaps chrony on start could use temperature measured by onboard
sensor to estimate the cold drift, if it can be sure that it was
started soon after the machine was booted up and stopped just before
halt.

It is hard to figure out what the temp of the rtc or computer oscillator crystal is since the cpu or motherboard temp sensors tend not to be near those crystals. The other problem is that you then also need to fit the temp changes to the
frequency changes, since each crystal is different AFAIK. Ie, it would require
a two dimensional fit of the data. In particular for chrony, with its
adaptation of past offsets via the current frequency/offset changes would make
a fairly complicated fitting procedure. But I suspect that fitting those temp variations would get rid of most of the
offsets, meaning that chrony would be running at max datasets most of the
time, knocking down the residual random noise by a lot.



I have an unfinished patch for runtime temperature compensation, I'll
see how hard it would be to improve it for the cold drift compensation.



--
William G. Unruh   |  Canadian Institute for|     Tel: +1(604)822-3273
Physics&Astronomy  |     Advanced Research  |     Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology |     unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1     |      and Gravity       |  www.theory.physics.ubc.ca/

---
To unsubscribe email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "unsubscribe" in the subject.
For help email chrony-dev-request@xxxxxxxxxxxxxxxxxxxx with "help" in the subject.
Trouble?  Email listmaster@xxxxxxxxxxxxxxxxxxxx.


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/