| 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 09:43:16AM -0700, Bill Unruh wrote:
I am confused. You have T0 as 26000 degrees-- far higher than the temp in the
interior of the sun.
It's 26 degrees, but it's reported by kernel as 26000 (probably to
to keep it always in integer).
Also, I am confused as to the philosophy. This program
operates behind the scenes and measures the temp, and alters the freq of the
computer clock directly it seems. But this is a direct fight with chrony. This
program assumes that there is some zero rate to the clock (ie k0, although k0
and T0 are ambiguous with respect to each other). and keeps trying to set that
rate. But chrony is measuring that zero rate and altering it. Thus the two
routines would seem to be fighting each other as to what the zero rate is.
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. 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? 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?
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.
If everything works well, the frequency plot created from tracking.log
should be closer to a straight line. And plot from tempcomp data is
something close to what would be tracking plot if compensation was
disabled.
The k0 coefficient is there only to keep the corrections below +-10ppm limit,
it's possible it will be never used.
It would seem to me that if you are going to have a temp compensation it
really needs to be integrated with the frequency and offset fitting routine.
Ie, each time an offset packet comes in from some source, the temp needs to be
measured as well, and then a 2D fit made to the offset and temp as a function
of time. That can then be used to set the clock. Ie, there is no value for k0
that can be fed in initially. At best you can have a value for k1 (the
derivative of rate with temp), and then compensate for changes in the temp.
I don't follow. That would be needed only in an adaptive system which
would work out the coefficients automatically, or not?
Yes, I agree, this would be implimenting a temperature compensated correction
to chrony. This is tough, since really one should be looking at the integral
of the temp between measurements as the correction factor, not the
instantaneous temp.
--
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.