[chrony-users] Can chrony correct very wrong RTC?

[Leo von Klenze]

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.

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

Can chrony handle such a case or do I have go get hwclock with
/etc/adjtime in place as well?

Thank you for any hints.

Best
 Leo

[Miroslav Lichvar]

Post by Leo von Klenze
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.

Post by Leo von Klenze
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?

Post by Leo von Klenze
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).

[Leo von Klenze]

Hi Miroslav,

thank you for your quick reply!

Post by Miroslav Lichvar

Post by Leo von Klenze
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.

Post by Miroslav Lichvar

Post by Leo von Klenze
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.

Post by Miroslav Lichvar

Post by Leo von Klenze
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

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.
--
Leo von Klenze
GeschÀftsfÌhrer
[phone]

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

[Miroslav Lichvar]

Post by Leo von Klenze
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

rtcsync or rtcfile+rtcautotrim?

Post by Leo von Klenze
3) on shutdown I ensure that the RTC is set to the Sysclock one last
time via hwclock

It's not very clear to me how this works :). I think hwclock has the
same requirement as chrony, that it has to be the only program
adjusting the clock, otherwise the measured drift will be incorrect. I
guess switching between them is possible, but when one adjusts the
RTC, I think the drift file of the other one needs to be updated.

[Bill Unruh]

William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
UBC, Vancouver,BC _|_ Program in Cosmology |____ ***@physics.ubc.ca
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Miroslav Lichvar

Post by Leo von Klenze
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

rtcsync or rtcfile+rtcautotrim?

Post by Leo von Klenze
3) on shutdown I ensure that the RTC is set to the Sysclock one last
time via hwclock

It's not very clear to me how this works :). I think hwclock has the
same requirement as chrony, that it has to be the only program
adjusting the clock, otherwise the measured drift will be incorrect. I
guess switching between them is possible, but when one adjusts the
RTC, I think the drift file of the other one needs to be updated.

I think what he is doing is to measure the drift of the rtc when the computer
if off once by hand. He then enters that drift rate by hand into the adjtime
file on each shutdown, and does not allow hwclock to set it.

Post by Miroslav Lichvar
--
Miroslav Lichvar
--
with "unsubscribe" in the subject.
with "help" in the subject.

[Leo von Klenze]

Post by Bill Unruh
William G. Unruh __| Canadian Institute for|____ Tel: [phone]
Physics&Astronomy _|___ Advanced Research _|____ Fax: [phone]
Canada V6T 1Z1 ____|____ and Gravity ______|_ www.theory.physics.ubc.ca/

Post by Miroslav Lichvar

Post by Leo von Klenze
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

rtcsync or rtcfile+rtcautotrim?

Post by Leo von Klenze
3) on shutdown I ensure that the RTC is set to the Sysclock one last
time via hwclock

It's not very clear to me how this works :). I think hwclock has the
same requirement as chrony, that it has to be the only program
adjusting the clock, otherwise the measured drift will be incorrect. I
guess switching between them is possible, but when one adjusts the
RTC, I think the drift file of the other one needs to be updated.

I think what he is doing is to measure the drift of the rtc when the computer
if off once by hand. He then enters that drift rate by hand into the adjtime
file on each shutdown, and does not allow hwclock to set it.

Exactly.

Post by Bill Unruh

Post by Miroslav Lichvar
-- 
Miroslav Lichvar
-- 
with "unsubscribe" in the subject.
with "help" in the subject.

--
Leo von Klenze
GeschÀftsfÌhrer
[phone]

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

[Bill Unruh]

Post by Leo von Klenze
Hi Miroslav,
thank you for your quick reply!

Post by Miroslav Lichvar

Post by Leo von Klenze
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.

Post by Leo von Klenze

Post by Miroslav Lichvar

Post by Leo von Klenze
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.

Post by Miroslav Lichvar

Post by Leo von Klenze
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
- 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.

Post by Leo von Klenze
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.

Post by Leo von Klenze
--
Leo von Klenze
GeschÀftsfÌhrer
[phone]
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]

Post by Bill Unruh

Post by Leo von Klenze
Hi Miroslav,
thank you for your quick reply!

Post by Miroslav Lichvar

Post by Leo von Klenze
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.

Post by Bill Unruh

Post by Leo von Klenze

Post by Miroslav Lichvar

Post by Leo von Klenze
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.

Post by Miroslav Lichvar

Post by Leo von Klenze
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
- 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.

Post by Leo von Klenze
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!

Post by Bill Unruh

Post by Leo von Klenze
-- 
Leo von Klenze
GeschÀftsfÌhrer
[phone]
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
[phone]

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

[Bill Unruh]

This post might be inappropriate. Click to display it.