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

[Bill Unruh <unruh@xxxxxxxxxxxxxx>]

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.