| Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-dev Archives
]
Hello Bill,
On 3/24/25 17:27, Bill Unruh wrote:
> I wastalking about giving the system clocks temperature compensation.
> Ie, use a thermometer on the motherboard (near the onboard clock if
> possible)
We only have sensors for the SoC itself and none on the board, so
temperature is highly susceptible to system load.
The systems are already deployed in the field and we are interested in a
solution that doesn't require a hardware retrofit.
The temperature compensation for the system clock is something that
we'll keep in mind though when a redesign is in order.
> What accuracy do you need?
We have not a hard requirement and the 15s drift we currently observe
with the RTC is acceptable to us.
> What are lengths of the times that the systerm have no> communication
with outside refclocks?
This can be up to a few months at a time.
> Is it more imporant that the
> clocks be
> synchronized to each other, or that their clocks accuratly follow UTC?
Following UTC is what's important to us. Of course, accuracy is going to
suffer when offline for longer spans of time, but we want to get the
best out of the hardware that's deployed.
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, Ahmad Fatoum wrote:
>
>> [CAUTION: Non-UBC Email]
>>
>> Hello Bill,
>>
>> Thanks for your input.
>>
>> On 3/24/25 16:41, Bill Unruh wrote:
>>> I would say no.
>>
>> It's the best clock we have on these systems for the spans of time,
>> where NTP synchronization is not possible.
>>
>> The SoC's external crystal is 24MHz ±30ppm, which is a drift of ±2.6
>> seconds a day in the worst case. Compare that to our RTC, which
>> according to vendor should deviate ±13 seconds at most within a month.
>>
>> My customer had compared both "wall" time (clocksource used by Linux
>> internally, derived from external oscillator) and RTC time and found the
>> latter to be considerably better in practice as well.
>>
>>> The rtc is alsays a bad clock.(and it can only be read
>>> to the nearet second).
>>
>> Yes, but many RTCs can output a Pulse-Per-Second interrupt, which Linux
>> supports and Userspace can poll(2) on. See RTC_UIE_ON in rtc(4).
>>
>> This is of course not as accurate as getting a subsecond granularity
>> timestamp out of the RTC directly, but it's still much better than just
>> reading the RTC and assuming half a second of error. The latter is also
>> supported in master as fallback for RTC reference clock when UIE is not
>> supported by the driver.
>>
>>> uUsing it as a refclock complicates the code, which
>>> introduces new possibilities of
>>> security and other bugs.
>>
>> RTC as Reference Clock is already implemented in the master branch.
>> I am asking about the next steps building on top of that.
>>
>>> 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).
>>
>> Our RTC has temperature compensation and it has shown significant
>> improvement on clock drift while active. We would like to benefit from
>> that by using it for periods of time, where we lack NTP synchronization
>> without having to juggle configs.
>>
>> 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, 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.