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:I've done some further experiments and I'm pretty sure now that this
Hello,That's bad. Unless the board is always running, so the drift doesn't
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.
change so much, I'm not sure how much the RTC support in chrony will
be useful.
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.
No, there are no errors. Chrony states the drift in rtcdata as long as
Is there anything chrony can do about it? I'm not quite sure out of theAFAIK there is no limit on the frequency error.
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).
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?
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 withIt depends on what are your expectations. It certainly won't be able
/etc/adjtime in place as well?
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 GmbH
www.scansation.de
Zielstattstr. 133, 81379
München
Geschäftsführer: Andreas Klett, Leo von Klenze
Amtsgericht München, HRB 227036