Re: [chrony-dev] Question / Feature suggestion - trimrtc on start?

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


trimrtc is supposed to occur such that the algorithm to determine the rtc
drift rate compensates for the change in rtc caused by the trinrtc (all
entries in the prior rtc measurement table are shifted by the same amt that
the rtc is). Thus calling trinrtc at anytime while running should not make a
difference. But doing it on bootup seems not a good idea. The system time is
not good then. You should wait until the system time has settled down.
Note that I believe hwclock now also estimates the rtc drift rate as well, so
chrony's rtc stuff is of less use now.
The other problem is that the drift rate is highly temperature dependent. And
the temp while the computer is off is very different than when it is on(when
chrony measures the drift rate). Ie the rtc drift calc is but a crude approx
to the off drift rate, but is not highly accurate. There is an argument for
not having the rtc stuff in chrony anymore.


On Wed, 20 Jul 2011, Ed W wrote:

Hi, Suppose I have a desire that chrony conditions my RTC, say because
the device is rebooted daily, internet isn't always on and the "off"
time might be significant and measured in days.  Lets also assume that
system is not shutdown cleanly most of the time (hey, lets just call it
the home router...)

Now, what are the negative implications of running "trimrtc" on boot?
The docs suggest that chrony internally updates itself to factor in the
rtc change? We can assume that it happens before any iburst or other
network connectivity is finished, so we aren't disturbing any
in-progress computation?  Additionally I'm naively assuming that the
previously calculated drift rates for the RTC are preserved, so even if
we immediately turn the machine off again, then when we turn on (some
days later) it will apply a sensible offset to the previously updated RTC?

Assuming the above then running trimrtc at chrony startup seems safe? As
such could we please have an option to do this automatically?
"trimrtconstart" or similar

The logic is that modern kernels set the clock from the RTC for you and
then on some machines I see a clock skew detected once chrony wakes up
and computes a better time by incorporating the known offset. One
solution would be to run chrony earlier in the boot (what does Redhat
do?).  My suggestion at least means that the next reboot might start
closer to the correct time (clearly depends a lot on reboot frequency).

(The point of this change is not about increasing accuracy, it's only
about decreasing the gap between RTC and clock, mainly to decrease the
opportunity for boot scripts to use the wrong one)



A related question is then - given I want chrony to learn a reasonable
estimate of RTC drift, plus I want to run trimrtc periodically, what is
a sensible frequency to set cron to call trimrtc?  Hourly, daily,
weekly?  What is the shortest sensible trim that will still lead to a
moderate estimate of RTC drift being learned?

Thanks

Ed W


---
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.


--
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/