[CAUTION: Non-UBC Email]
I would say no. The rtc is alsays a bad clock.(and it can only be read to
the
nearet second). uUsing it as a refclock complicates the code, which
introduces new possibilities of
security and other bugs. It may be the best you have to initialise the
clock.
Probably a better idea would be to enable temperature tracking as an
additional input in the local clock algorithm, since teperature
fluctuations
are probably the main cause of clock noie. (Chrony already has this
possibility).
William G. Unruh __|__Hagler Fellow, Distinguished |_Tel:UBC +1(604)822-3273
Physics&Astronomy _|__ Research Prof, IQSE |__ US +1(979)7399950
UBC, Vancouver,BC _|_ TAMU4242, 578 University Dr |_ unruh@xxxxxxxxxxxxxx
Canada V6T 1Z1 ____|__College Stn, Tx, USA 77843
_|_www.theory.physics.ubc.ca
I cannot reply to emails from outlook or hotmail or other microsoft domains.
On Mon, 24 Mar 2025, Ahmad Fatoum wrote:
[CAUTION: Non-UBC Email]
Hi,
Last year I upstreamed some patches to allow use of Linux /dev/rtc as
reference clock.
This helped us on an embedded system that can be offline for multiple
days at a time and the clock drift of the SoC's internal timer was
higher than tolerable, compared to that of the external RTC.
With the support now in master, it's possible to keep two configs, one
for each of NTP and RTC as reference clock and switching between them as
needed.
The logical next step would be to allow having a single config that
addresses our use case, which I believe would be a generally useful
default for many embedded system:
- The kernel allows only one process to open /dev/rtc at a time.
Chrony should gain an IPC command by which chronyc can set the time
on the RTC, when used as reference clock.
- Setting the time this way, discards all samples and then sampling
starts fresh with a clean slate
- The RTC reference clock should only be selected, when there are no
other usable non-RTC reference clocks
- The 11-minute kernel programming of the RTC must always be disabled,
once a RTC reference clock has been initialized
- rtcsync when the RTC is a selected reference clock should be a no-op
- rtcsync when the RTC is _not_ the selected reference clock should
periodically program the time into the RTC like the kernel usually
does, once the drift exceeds a threshold
A future follow-up to that could be using RTC_PARAM_CORRECTION to
compensate RTC oscillator imprecision.
Does this make sense? Any comments before I try implementing it?
Thanks!
Ahmad
--
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.
--
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.