Re: How to read the RTC value?

chrony will also keep the rtc near the system time. See https://wiki.archlinux.org/title/Chrony
and the trimrtc rtcautotrim and rtcsync commands.
trimrtc and rtcautotrim keep track of the rtc drift rate(how many ppm the rtc runs
slow or fast of the system time) at the expense of using rtcfile and hogging the rtc and not
allowing any other program to read the rtc (eg hwclock or timedatectl)
See also man chrony.conf.
rtcsync copies the systemtime to the rtc (plus or minus half a second) and
makes no attempt to determine the rtc drift.

chrony uses the rtc drift and rtcoffset  information (as read from the rtc file) at bootup to
correct the time to which the system time is set at bootup.

That sounds great, but has a problem in that the drify is measured while the
computer id running, and thus is hot, while at bootup the system has been cold
since it was shut down, and the drift rate depends on the temperature. How big
an effect that is depends on the quality of the rtc chip. And the rtc is not
somewhere that manufacturers want to spend any money. Almost nobody cares
about the rtc time especially since one can only read or set the rtc to the
nearest second anyway.

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 |____ [email protected]
Canada V6T 1Z1 ____|____ and Gravity ______|_    theory.physics.ubc.ca/

On Sat, 10 Aug 2024, Jan Claußen wrote:

> [CAUTION: Non-UBC Email]
>
> Thank you for the extended explanation again! I don’t view the RTC as a correct source. I was just playing around with very wrong RTC values and wanted to verify if chrony corrects them. I mean you can always do this with timedatectl after disabling chronyd, but it is just tedious. Anyway, not so important I guess.
>
>> Am 09.08.2024 um 21:36 schrieb Bill Unruh <[email protected]>:
>>
>> The rtc works correctly if it counts out its own seconds. It's seconds need
>> not be the same as UTC seconds for it to work although they should not be too
>> far off. It is not supposed to an accurate source of UTC time. Just good
>> enough to start of nptd or chrony with roughly ( within a few hours) the
>> correct UTC time. After that you use either a good clock (atomic clock, GPS
>> time,..) or an internet ntp server to get the time reallywall ( to msec or
>> microseconds which an RTC cannot do and was never designed to do) For nsec
>> accuracy you need to put in much more work and money, and it is easy to get
>> wrong (see the brouha about 10 years ago when neutrinos were measured to go
>> faster than light. It turned out to be clock problem at nsec accuracy, not a neutrino problem.
>> And that was a multi million dollar experiment, with some really very bright
>> people running it. It turned out to be a bad fibre optics connection between
>> the gps receiver and the experiment, which delayed the time signal by a nsec
>> or so). nsec are hard. microseconds are cheap (<$100) and easy (even I can do
>> it).
>>
>> 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 |____ [email protected]
>> Canada V6T 1Z1 ____|____ and Gravity ______|_    theory.physics.ubc.ca/
>>
>>> On Fri, 9 Aug 2024, Jan Claußen wrote:
>>>
>>> [CAUTION: Non-UBC Email]Well, it is simple. I want to compare if the RTC syncing was successfull and compare
>>> the times like I can with timedatectl. This way you can visibly verify that the RTC works correctly. I don't
>>> want to calculate anything for this.
>>> It is just one line more to add to the rtcdata command. I really don't understand why this was never
>>> implemented.
>
>
> -- 
> To unsubscribe email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org
> with "unsubscribe" in the subject.
> For help email chrony-users-request-kWFZVVI9zxvPqho9SqqRMmD2FQJk+8+b@public.gmane.org
> with "help" in the subject.
> Trouble?  Email [email protected]
>
>