| Re: [chrony-dev] temperature compensation |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
On Tue, 13 Apr 2010, Miroslav Lichvar wrote:
On Tue, Apr 13, 2010 at 12:31:40PM -0700, Bill Unruh wrote:
On Tue, 13 Apr 2010, Miroslav Lichvar wrote:
I don't think they are in conflict. The temperature corrections are
not visible to upper layers as the local module adjust the frequency
in both directions. When sourcestats sets the frequency to f and local
module corrects it by c, it will get only f when reading frequency
back. Also, the temperature corrections are done independently from
source updates and they may (or should?) happen more frequently. One
of the main points is that reading temperature is cheaper than
querying NTP server.
I am not sure how the temp corrections are actually done. Let us say you
measure the temp at some time you find it is 26000 (26 degrees), so there is
"no correction". Does this mean that you set the clock rate to 0
(adjtimex setting tickvalue and newfreq to 0)? That would certainly fight
chrony which has say set newfreq to 7000.
No, the freq will stay at 7000.
Now the temp changes to 27000 (it is
quantized in units of 1000). Your formula now gives 1.8PPM. Do you now change
newfreq to this 1.8PPM value, or do you add that 1.8PPM to the current rate of
the clock?
It will be added to the current rate. (it's only 0.183 ppm actually)
Ah, so it is the differences in the temp that alter the rate, not the temp
itself.
Now at the next time, the temp is again 27000. Do you leave the
rate alone, or do you adjust it by 1.8PPM again, or do you set the clock rate
to 1.8PPM?
There will be no change in rate.
If you use only the changes in temp to adjust the clock, then T0 (and k0) are
irrelevant. If you use the absolute temp to adjust the clock rate then I
cannot see how it cannot fight with chrony.
I believe T0 is needed for the quadratic coefficient. And k0 is there
only to get the result below 10 ppm if T0 is very high or low. If the
correction is outside +-10 ppm, it will be ignored. This is to avoid
accidents if the sensor fails, noise, etc.
Your actual model is then seems to be
delta R = k1 delta T
where delta R is the change in rate, and delta T is the change in temp from
the last reading. Your second order term might be to have k1 depend on the temp. itself.
This whole system could simply be set up as a separate program, rather than as
a part of chrony which could then also control ntpd. Of course it would be
best if the computer figured out the coefficients, rather than people doing it
by hand.
One difficulty is that the slope is determined well after the fact. Ie, if the
slope changes now, it will be many poll intervals before the system knows that
the frequency has changed.
--
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.