| Re: [chrony-users] Can chrony correct very wrong RTC? |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
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/
On Tue, 30 Oct 2018, Leo von Klenze wrote:
Am 18.10.18 um 21:36 schrieb Bill Unruh:
On Thu, 18 Oct 2018, Leo von Klenze wrote:
Hi Miroslav,
thank you for your quick reply!
On 10/15/18 10:31 AM, Miroslav Lichvar wrote:
On Mon, Oct 15, 2018 at 10:10:38AM +0200, Leo von Klenze wrote:
Hello,
I've a cubietruck with a very weird RTC. It is off by about 2384
seconds
per day if the box is not running. While running the offset is just
about 480s per day.
That's bad. Unless the board is always running, so the drift doesn't
change so much, I'm not sure how much the RTC support in chrony will
be useful.
I've done some further experiments and I'm pretty sure now that this
task cannot be handled by chrony alone due to the different drift if
running/stopped.
Yes. Chrony measures the rate of the RTC while chrony is running. It
assumes
that that rate is also the rate of the rtc when chrony is not running
(eg the
computer is off). That is about all it can do. It then corrects the
rtc time
assuming that rate. Now if you know that the rate when off is some
sec/sec.,
you could probably rewrite chrony to use that rate instead of the rate
calculated when the system is on.
Sounds reasonable.
You could also get chrony to estimate the "off" rate. Read and save the rtc
when the system goes off (having synchronized the rtc using chrony). then when
it comes on again, wait until the system clock has been synchronized by
chrony, and measure how far the rtc is off.
Then save that as the "off" rate. Of course without knowing why the system is
showing such drastidally different rates for rtc when the computer is off or
on, it is hard to know if this reasonable. for exmaple the rtc may simply have
a huger temperature coefficient, so that then you would also have to know what
the temp is when the computer is off. Eg if the temp coesfficient where
100PPM/degree, then it would be almost impossible snce you almost certainly
cannot control the temp to milli degrees when the computer is off.
Is there anything chrony can do about it? I'm not quite sure out of
the
docs what chrony exactly is doing with the drift f the RTC. I'm using
rtcfile option in config and "-s" switch on startup. However chrony
sets
the system clock from the RTC on startup but without any correction
(as
far as I can see).
AFAIK there is no limit on the frequency error.
Are there any errors from chronyd in the system log? What does the rtc
file contain when chronyd is starting? What does "chronyc rtcdata"
print?
No, there are no errors. Chrony states the drift in rtcdata as long as
the RTC is not synchronized with the SysClock. Afterwards rtcdata
reports no drift anymore.
Can chrony handle such a case or do I have go get hwclock with
/etc/adjtime in place as well?
It depends on what are your expectations. It certainly won't be able
to compensate for the "off" drift.
You can try hwclock, but I doubt it would do better (assuming chrony
works as expected).
I've implemented the following scenario now and it seems to work well
enough:
- I've calculated once the drift when box is powered off and written it
to /etc/adjtime
1) on boot I set the Sysclock from the RTC via hwclock. hwclocks uses
the drift from /etc/adjtime
2) afterwards chrony is started and I configured chrony to synchronize
the RTC on runtime
3) on shutdown I ensure that the RTC is set to the Sysclock one last
time via hwclock
But of course while chrony is running, the rtc is not used by
anything(?). So
whether or not chrony knows what the drift rate is seems to be
irrelevant.
So hwclock manages the drift during power off, chrony during running. It
seems to qork quite well.
As far as I've understood now, it is just hard for chrony to manage both
drifts since they are that different.
I think a more profitable use of time is to figure out why in the
world your
rtc shows such a driastically different rate on shutdown than when
running. It
should not. It is a really defective RTC if it does.
Yes, you are right. It seems to be a design? bug on the Cubietruck. I've
this problem with at least 10 Cubietrucks. Very weird.
Thank you for your thoughts and clarifications!
--
Leo von Klenze
Geschäftsführer
+49 176 10072624
Scansation ist Top Supplier Retail 2018!
Scansation GmbH
www.scansation.de
Zielstattstr. 133, 81379 München
Geschäftsführer: Andreas Klett, Leo von Klenze
Amtsgericht München, HRB 227036
--
Leo von Klenze
Geschäftsführer
+49 176 10072624
Scansation ist Top Supplier Retail 2018!
Scansation GmbH
www.scansation.de
Zielstattstr. 133, 81379 München
Geschäftsführer: Andreas Klett, Leo von Klenze
Amtsgericht München, HRB 227036