Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC

[Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx>]

Hi Bill,

On 3/24/25 16:56, Bill Unruh wrote:
> See for example https://blog.dan.drown.org/beaglebone-black-ntpgps-
> server-temperature-compensation/
> 
> He found .7 ppm chnge for 5 degrees C. Over days that could well
> accumulate.
> Note that this depends on the clock crystal, and is not a universal
> property
> of clock chips.Ie, you have to calibrate your own clock chips.

Thanks, I will check out. But as I just wrote in the other mail, the RTC
does temperature compensation, so the logical next step is to benefit
from that for the times, where we are not NTP-synchronized.

> Note that rtc chips are liable to have much worse temperature sensitivity--
> they are cheaper items since one only expects to use them very very
> sporadically.
> 
> You give no indication of what accuracy you need or what the situation is.

I must admit that I am not very familiar with the quality of RTCs built
into PC motherboards. For embedded use cases, RTCs are sometimes the
only timesource available besides manual time entry and thus there is a
greater reliance on their quality.

FWIW, here is the datasheet of the RX-4803 RTC that we are using:
https://support.epson.biz/td/ps/productinfo.php?pn=X1B0001310001

AFAIR, the japanese manual has some more info regarding temperature
compensation that's lacking from the English edition.

Thanks,
Ahmad

> 
> 
> 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, Bill Unruh wrote:
> 
>> [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.
>>
>>
>>
> 


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