Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
On Thu, Jul 03, 2025 at 06:53:19PM +, Christoph Schittel wrote: > > > Can you please explain the use case? > > > At the time the limit of 16s was implemented in the kernel, this was an > reasonable choice. Today for many applications even a (possible) deviation > of 1s or less may be regarded as too big and the system should be signaling > it by setting STA_UNSYNC. Reading David R. Mills documentation reads like > the syncing service should set STA_UNSYNC. The kernel setting it, when > maxerror reaches 16s was just meant as last resort. Applications that need to know the maximum error should examine the timex maxerror directly. Different applications running on the same system may have different requirements, so one threshold in chrony to set the flag globally could not work for all applications. In this thread it was about setting the flag in order to disable the kernel 11-minute system clock->RTC copy process to avoid a synchronization loop when the system clock is synchronized to RTC by chronyd. > (Remote) monitoring services could benefit, because hosts with sync problems > could be very easily detected. E.g. NAGIOS instead monitors the clock > difference between itself and remote hosts. This implies the monitoring host > has the "right" time. This could be improved by reading remote hosts > STA_UNSYNC, if it will be set when needed (which should be the admin's > choice, not the kernel's). NTP has root delay + dispersion (combined as root distance) for estimating the maximum error. That's what should normally be monitored, not a flag. -- Miroslav Lichvar -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
You could tell us what the problem, for yourself, would be solved, not
hypothetical cases or problems. That 16 sec is an extremely hypothetical
situation, with the clock actually out by far less than that because of of the
very hypothetical "error" that 16 sec represents. Every new adjustable item
increases the chance of bugs, of confusing the user ("Why not make it a
nanosecond instead of 16 sec and make sure my server is sevinv extrememly
accurate time").
Now if you were to present an actual use case that you had run into where it
would have made a difference, it would be strongr argument.
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 |_ [email protected]
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 Thu, 3 Jul 2025, Christoph Schittel wrote:
[CAUTION: Non-UBC Email]
Miroslav Lichvar schrieb am Donnerstag, 3. Juli 2025 09:19:17 (+02:00):
On Wed, Jul 02, 2025 at 09:59:39PM +0200, Christoph Schittel wrote:
> Could you add an option to force STA_UNSYNC when reaching a settable
limit?
Can you please explain the use case?
At the time the limit of 16s was implemented in the kernel, this was an
reasonable choice. Today for many applications even a (possible) deviation of
1s or less may be regarded as too big and the system should be signaling it
by setting STA_UNSYNC. Reading David R. Mills documentation reads like the
syncing service should set STA_UNSYNC. The kernel setting it, when maxerror
reaches 16s was just meant as last resort.
(Remote) monitoring services could benefit, because hosts with sync problems
could be very easily detected. E.g. NAGIOS instead monitors the clock
difference between itself and remote hosts. This implies the monitoring host
has the "right" time. This could be improved by reading remote hosts
STA_UNSYNC, if it will be set when needed (which should be the admin's
choice, not the kernel's).
regards,
Christoph
--
To unsubscribe email [email protected] with
"unsubscribe" in the subject.
For help email [email protected] with "help" in the
subject.
Trouble? Email [email protected].
--
To unsubscribe email [email protected] with "unsubscribe"
in the subject.
For help email [email protected] with "help" in the
subject.
Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
Miroslav Lichvar schrieb am Donnerstag, 3. Juli 2025 09:19:17 (+02:00): > On Wed, Jul 02, 2025 at 09:59:39PM +0200, Christoph Schittel wrote: > > Could you add an option to force STA_UNSYNC when reaching a settable limit? > > Can you please explain the use case? > At the time the limit of 16s was implemented in the kernel, this was an reasonable choice. Today for many applications even a (possible) deviation of 1s or less may be regarded as too big and the system should be signaling it by setting STA_UNSYNC. Reading David R. Mills documentation reads like the syncing service should set STA_UNSYNC. The kernel setting it, when maxerror reaches 16s was just meant as last resort. (Remote) monitoring services could benefit, because hosts with sync problems could be very easily detected. E.g. NAGIOS instead monitors the clock difference between itself and remote hosts. This implies the monitoring host has the "right" time. This could be improved by reading remote hosts STA_UNSYNC, if it will be set when needed (which should be the admin's choice, not the kernel's). regards, Christoph -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
On Wed, Jul 02, 2025 at 09:59:39PM +0200, Christoph Schittel wrote: > Hi Miroslav! > > It would be good in general (rtc mode or not) to have control over > STA_UNSYNC. To be raised at 1s or 2s acummulated error, independend of the > kernel. > > Could you add an option to force STA_UNSYNC when reaching a settable limit? Can you please explain the use case? -- Miroslav Lichvar -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
Hi Miroslav! It would be good in general (rtc mode or not) to have control over STA_UNSYNC. To be raised at 1s or 2s acummulated error, independend of the kernel. Could you add an option to force STA_UNSYNC when reaching a settable limit? Regards, Christoph Miroslav Lichvar schrieb am Mi., 2. Juli 2025, 15:08: > 16 seconds is the maximum value that the kernel can keep as esterror > and maxerror. It would automatically set the STA_UNSYNC flag if the > application didn't set it. Normally, if the clock is well > synchronized, it takes a few days for that threshold to be reached. > > > >
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
On Wed, Jul 02, 2025 at 03:15:19PM +0200, Ahmad Fatoum wrote: > Do you think it can make sense to set STA_UNSYNC in chrony when NTP is > unreachable in some situations or should rtcsync be just refused always > in favor of rtcfile when RTC local refclock is used? The latter makes more sense to me. -- Miroslav Lichvar -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
On 7/2/25 15:08, Miroslav Lichvar wrote: > On Wed, Jul 02, 2025 at 02:55:02PM +0200, Ahmad Fatoum wrote: >>> chronyd does not set the STA_UNSYNC flag when it loses its upstream >>> sources. >> >> Oh. Then I have trouble understanding the code in set_sync_status, which >> compares max_error against MAX_SYNC_ERROR (== 16s) as it looks like that >> would cause STA_UNSYNC to be set once the threshold is exceeded. > > 16 seconds is the maximum value that the kernel can keep as esterror > and maxerror. It would automatically set the STA_UNSYNC flag if the > application didn't set it. Normally, if the clock is well > synchronized, it takes a few days for that threshold to be reached. I > assume you are interested in much shorter intervals. I see. I think the relevant Linux kernel code would be the check against NTP_PHASE_LIMIT in kernel/time/timekeeping.c second_overflow(). Do you think it can make sense to set STA_UNSYNC in chrony when NTP is unreachable in some situations or should rtcsync be just refused always in favor of rtcfile when RTC local refclock is used? Thanks very much, Ahmad > -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
On Wed, Jul 02, 2025 at 02:55:02PM +0200, Ahmad Fatoum wrote: > > chronyd does not set the STA_UNSYNC flag when it loses its upstream > > sources. > > Oh. Then I have trouble understanding the code in set_sync_status, which > compares max_error against MAX_SYNC_ERROR (== 16s) as it looks like that > would cause STA_UNSYNC to be set once the threshold is exceeded. 16 seconds is the maximum value that the kernel can keep as esterror and maxerror. It would automatically set the STA_UNSYNC flag if the application didn't set it. Normally, if the clock is well synchronized, it takes a few days for that threshold to be reached. I assume you are interested in much shorter intervals. -- Miroslav Lichvar -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
Hello Miroslav, On 7/2/25 14:37, Miroslav Lichvar wrote: > On Tue, Jul 01, 2025 at 03:25:29PM +0200, Ahmad Fatoum wrote: >> On 4/7/25 16:52, Miroslav Lichvar wrote: >>> That should force the first adjustment to accumulate the "local" >>> refclock's frequency offset and track it closely until a time source >>> is selected. I suspect there could be numerical errors accumulating >>> over long periods of time, but insignificant when compared to a real >>> time source like RTC. >>> >>> It could be a new option, if I can get a name for it. >> >> I called it bootstraptime and included it in merge request #27, which I >> submitted today. > > Ok, thanks. I'll have a look. > >>> rtcsync cannot work. That's the kernel doing changes at random times >>> unknown to chronyd.I think it could work with rtcfile if it shared >>> the descriptor and timestamps with the refclock driver. >> >> AFAIU, the kernel will not program the RTC while STA_UNSYNC is set and >> I'd expect chrony to eventually clear the bit after losing NTP sync. >> >> This sounds like the behavior I am after: While NTP synchronized, >> program the RTC. When all offline and RTC is local ref clock, do not >> keep updating it with system time. Am I missing something? > > chronyd does not set the STA_UNSYNC flag when it loses its upstream > sources. Oh. Then I have trouble understanding the code in set_sync_status, which compares max_error against MAX_SYNC_ERROR (== 16s) as it looks like that would cause STA_UNSYNC to be set once the threshold is exceeded. > It still considers the clock to be synchronized, it just > grows the estimated error over time. The kernel should still be > copying system time to the RTC.. I am still trying to wrap my head around the implications. But if rtcsync is indeed not salvageable for the local RTC refclock case, I'd look into making rtcfile usable instead. Cheers, Ahmad -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
On Tue, Jul 01, 2025 at 03:25:29PM +0200, Ahmad Fatoum wrote: > On 4/7/25 16:52, Miroslav Lichvar wrote: > > That should force the first adjustment to accumulate the "local" > > refclock's frequency offset and track it closely until a time source > > is selected. I suspect there could be numerical errors accumulating > > over long periods of time, but insignificant when compared to a real > > time source like RTC. > > > > It could be a new option, if I can get a name for it. > > I called it bootstraptime and included it in merge request #27, which I > submitted today. Ok, thanks. I'll have a look. > > rtcsync cannot work. That's the kernel doing changes at random times > > unknown to chronyd.I think it could work with rtcfile if it shared > > the descriptor and timestamps with the refclock driver. > > AFAIU, the kernel will not program the RTC while STA_UNSYNC is set and > I'd expect chrony to eventually clear the bit after losing NTP sync. > > This sounds like the behavior I am after: While NTP synchronized, > program the RTC. When all offline and RTC is local ref clock, do not > keep updating it with system time. Am I missing something? chronyd does not set the STA_UNSYNC flag when it loses its upstream sources. It still considers the clock to be synchronized, it just grows the estimated error over time. The kernel should still be copying system time to the RTC.. -- Miroslav Lichvar -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
On 7/1/25 15:25, Ahmad Fatoum wrote: > On 4/7/25 16:52, Miroslav Lichvar wrote: > AFAIU, the kernel will not program the RTC while STA_UNSYNC is set and > I'd expect chrony to eventually clear the bit after losing NTP sync. s/clear the bit/set the bit/ -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
Hello Miroslav,
On 4/7/25 16:52, Miroslav Lichvar wrote:
> On Mon, Mar 31, 2025 at 05:38:11PM +0200, Ahmad Fatoum wrote:
>>> I.e. use it only for stabilization of the system clock, not as a time
>>> source. That would work even when it's synchronizing to NTP servers.
>>> When NTP is not reachable, it would activate the local reference as
>>> configured by the local directive. I guess something would be needed
>>> for the case when it's started without NTP.
>>
>> Do you have a suggestion how to go about it?
>
> Try it with this patch:
>
> --- a/refclock.c
> +++ b/refclock.c
> @@ -732,7 +732,13 @@
>SST_Stats stats = SRC_GetSourcestats(inst->source);
>
>if (SST_Samples(stats) < SST_GetMinSamples(stats)) {
> +#if 0
> UTI_ZeroTimespec(ref);
> +#else
> +LCL_ReadCookedTime(ref, NULL);
> +*freq = 0.0;
> +*offset = 0.0;
> +#endif
> return;
>}
>
> That should force the first adjustment to accumulate the "local"
> refclock's frequency offset and track it closely until a time source
> is selected. I suspect there could be numerical errors accumulating
> over long periods of time, but insignificant when compared to a real
> time source like RTC.
>
> It could be a new option, if I can get a name for it.
I called it bootstraptime and included it in merge request #27, which I
submitted today.
>> I also think that even if
>> local works for us, we still need to address the synchronization of the
>> RTC to system time when the system is NTP-synchronized.
>>
>> Currently, chrony disallows rtc reference clock to co-exist with
>> rtcsync, but maybe we should allow it and enable the rtcsync only when
>> NTP is reachable and the RTC is local and not activated?
>
> rtcsync cannot work. That's the kernel doing changes at random times
> unknown to chronyd.I think it could work with rtcfile if it shared
> the descriptor and timestamps with the refclock driver.
AFAIU, the kernel will not program the RTC while STA_UNSYNC is set and
I'd expect chrony to eventually clear the bit after losing NTP sync.
This sounds like the behavior I am after: While NTP synchronized,
program the RTC. When all offline and RTC is local ref clock, do not
keep updating it with system time. Am I missing something?
Thanks,
Ahmad
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe email [email protected] with "unsubscribe"
in the subject.
For help email [email protected] with "help" in the
subject.
Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
Hello Dan, On 4/1/25 19:38, Dan Drown wrote: > On 4/1/2025 8:08 AM, Ahmad Fatoum wrote: > : >> We have measured the accuracy we get out of our RTC as mentioned before >> and it's sufficient for our use case. Epson sells this RTC as "High- >> Stability", >> so I do not refuse the claim that cheaper RTCs can be much worse. > : >> This is a wrong summary of my proposal. The RTC is only used as reference >> clock while the system has no network connectivity. Once online, >> system time >> is synchronized against NTP and the RTC is reset to UTC to be better >> equipped >> for the next offline period. > : > > Does your RTC output a PPS and is that PPS connected to a CPU GPIO? If > so, you can use the "local" option to the PPS refclock: > https://chrony-project.org/doc/4.6.1/chrony.conf.html#refclock Yes, the RTC interrupt is connected to a CPU GPIO. > Chrony can use that to correct the system's frequency and improve the > timekeeping while offline. I have some more details on: https:// > blog.dan.drown.org/strat-2-tcxo/ Thank you. This was insightful. I prefer not to go the PPS route though, but use local as you do for the RTC reference clock instead. That way the kernel driver can be used as-is to set up the periodic interrupt. Thanks, Ahmad -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
On Mon, Mar 31, 2025 at 05:38:11PM +0200, Ahmad Fatoum wrote:
> > I.e. use it only for stabilization of the system clock, not as a time
> > source. That would work even when it's synchronizing to NTP servers.
> > When NTP is not reachable, it would activate the local reference as
> > configured by the local directive. I guess something would be needed
> > for the case when it's started without NTP.
>
> Do you have a suggestion how to go about it?
Try it with this patch:
--- a/refclock.c
+++ b/refclock.c
@@ -732,7 +732,13 @@
SST_Stats stats = SRC_GetSourcestats(inst->source);
if (SST_Samples(stats) < SST_GetMinSamples(stats)) {
+#if 0
UTI_ZeroTimespec(ref);
+#else
+LCL_ReadCookedTime(ref, NULL);
+*freq = 0.0;
+*offset = 0.0;
+#endif
return;
}
That should force the first adjustment to accumulate the "local"
refclock's frequency offset and track it closely until a time source
is selected. I suspect there could be numerical errors accumulating
over long periods of time, but insignificant when compared to a real
time source like RTC.
It could be a new option, if I can get a name for it.
> I also think that even if
> local works for us, we still need to address the synchronization of the
> RTC to system time when the system is NTP-synchronized.
>
> Currently, chrony disallows rtc reference clock to co-exist with
> rtcsync, but maybe we should allow it and enable the rtcsync only when
> NTP is reachable and the RTC is local and not activated?
rtcsync cannot work. That's the kernel doing changes at random times
unknown to chronyd. I think it could work with rtcfile if it shared
the descriptor and timestamps with the refclock driver.
--
Miroslav Lichvar
--
To unsubscribe email [email protected] with "unsubscribe"
in the subject.
For help email [email protected] with "help" in the
subject.
Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
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 |_ [email protected] > 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 [email protected] with >> "unsubscribe" in the subject. >> For help email [email protected] with "help" in >> the subject. >> Trouble? Email [email protected]. >> >> > -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
Hello Miroslav, Thanks for your feedback. On 3/25/25 14:46, Miroslav Lichvar wrote: > On Mon, Mar 24, 2025 at 04:26:31PM +0100, Ahmad Fatoum wrote: [snip] >> - 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 > > This looks like a significant complication. I prefer to keeps things > simple if possible, avoiding fallbacks and switching between different > modes of operation. I am open to less complicated ways to achieve this that don't require us to restart chrony with different configs. > Have you considered using the local option for the RTC refclock? I was not aware for it and will try it out. > I.e. use it only for stabilization of the system clock, not as a time > source. That would work even when it's synchronizing to NTP servers. > When NTP is not reachable, it would activate the local reference as > configured by the local directive. I guess something would be needed > for the case when it's started without NTP. Do you have a suggestion how to go about it? I also think that even if local works for us, we still need to address the synchronization of the RTC to system time when the system is NTP-synchronized. Currently, chrony disallows rtc reference clock to co-exist with rtcsync, but maybe we should allow it and enable the rtcsync only when NTP is reachable and the RTC is local and not activated? Thanks, Ahmad -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
On 4/1/2025 8:08 AM, Ahmad Fatoum wrote: : We have measured the accuracy we get out of our RTC as mentioned before and it's sufficient for our use case. Epson sells this RTC as "High-Stability", so I do not refuse the claim that cheaper RTCs can be much worse. : This is a wrong summary of my proposal. The RTC is only used as reference clock while the system has no network connectivity. Once online, system time is synchronized against NTP and the RTC is reset to UTC to be better equipped for the next offline period. : Does your RTC output a PPS and is that PPS connected to a CPU GPIO? If so, you can use the "local" option to the PPS refclock: https://chrony-project.org/doc/4.6.1/chrony.conf.html#refclock Chrony can use that to correct the system's frequency and improve the timekeeping while offline. I have some more details on: https://blog.dan.drown.org/strat-2-tcxo/ -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
Hello Bill, I have transplanted the outgrowth of this subthread's discussion back. I had to forward some questions internally and needed time till I could adequately respond. Raising the same point over there only makes the discussion tedious for all participants IMO. On 4/1/25 00:30, Bill Unruh wrote: > Yes, it is possible. Unfortunately the RTC was never designed to be a > particularly accurate clock. We have measured the accuracy we get out of our RTC as mentioned before and it's sufficient for our use case. Epson sells this RTC as "High-Stability", so I do not refuse the claim that cheaper RTCs can be much worse. > The OP now wants the RTC to get its time > from the > system clock as well, which means that the RTC is no better than the system > clock, which are are then using to discipline the system clock. This is a wrong summary of my proposal. The RTC is only used as reference clock while the system has no network connectivity. Once online, system time is synchronized against NTP and the RTC is reset to UTC to be better equipped for the next offline period. > But for many rtc you cannot set the RTC with any accuracy either (I recall > that it > has a .6 > second offset on setting the clock, and can only set it to within a > second). I don't know which RTC you're referring to in particular. This is highly dependent on the type of RTC and, in our case, the I2C frequency. Our RX-4803 allows setting time in units of 10ms if required, but we don't need that: If we are going to drift by several seconds a month anyway, subsecond deviation is lost in the noise. > As I mentioned far better is to use the thermal discipline in chrony to > make > the system clock much better behaved and then use the system clock > throughout > > a few thousandth of a second accuracy, is millisecond accuracy. This is not an option with our existing hardware unfortunately. > Network time > is good to a few microsecond. GPS discipline on chrony is good to a few > hundred nanoseconds. We have no idea what accuracdy he needs. The devices tend to be deployed in locations with weak GPS coverage, e.g. building basements. 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 |_ [email protected] > 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, 31 Mar 2025, John Gilmore wrote: > >> [CAUTION: Non-UBC Email] >> >> Bill Unruh wrote: >>> Not at all clear why you want to go via the rtc since it can only >>> be queried to the nearest second anyway. >> >> It's really simple to get an RTC timestamp that is accurate to much >> more than 1 second. You don't even need to use an RTC interrupt. >> Software can come to the rescue of dimly built hardware. >> >> Basically, your sofware loops as tightly as possible, reading the RTC, >> and notice when it increments. It will take you a maximum of 1 second >> of tight polling to do that. Then you have captured the tick as >> accurately as the frequency with which you can query the RTC (many >> thousands of times per second). >> >> (There are complications if running multi-threaded when your polling >> loop might be interrupted by other tasks, which you must take care >> to account for the possibility of.) >> >> If you don't want to dedicate a core or a bus to a continuous 1-second >> loop, and you already have a higher-resolution timer in the system (as >> in a modern PC Linux system), you can do this just as well over a few >> seconds, with much lower (largely invisible) overhead. >> >> Poll the RTC once, delay your polling process by a tenth of a second (as >> measured by your higher resolution timer -- letting other tasks run >> during that time), then poll it again. Loop on that. When you see it >> has incremented, then you know (within your process scheduling latency + >> 1/10th second) the phase of when it ticked. Now schedule a delay until >> a tenth of a second before you think it will next tick. After the >> delay, do the high-speed loop reading the RTC and waiting for it to >> tick; that should only take you 1/10th of a second of dedicating >> polling. You can insert a middle phase in which you do e.g. .01 second >> delays in order to creep up on when you believe it will tick. What you >> want is to have your tight loop start running JUST BEFORE you think the >> RTC will tick, so it will read the old value, then only spin perhaps a >> few dozen or few hundred times, before it sees an accurately caught tick. >> >> Then NTP can condition your high resolution (but volatile and drifty) >> clock based on the recent tick. You're done. You can do this at >> whatever frequency you like to measure the drift between the HR time >> and the RTC. >> >> John Gilmore >> >> >>
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
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 |_ [email protected] > 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 |_ >>> [email protected] >>> 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.
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
Yes, it is possible. Unfortunately the RTC was never designed to be a particularly accurate clock. The OP now wants the RTC to get its time from the system clock as well, which means that the RTC is no better than the system clock, which are are then using to discipline the system clock. But for many rtc you cannot set the RTC with any accuracy either (I recall that it has a .6 second offset on setting the clock, and can only set it to within a second). As I mentioned far better is to use the thermal discipline in chrony to make the system clock much better behaved and then use the system clock throughout a few thousandth of a second accuracy, is millisecond accuracy. Network time is good to a few microsecond. GPS discipline on chrony is good to a few hundred nanoseconds. We have no idea what accuracdy he needs. 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 |_ [email protected] 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, 31 Mar 2025, John Gilmore wrote: [CAUTION: Non-UBC Email] Bill Unruh wrote: Not at all clear why you want to go via the rtc since it can only be queried to the nearest second anyway. It's really simple to get an RTC timestamp that is accurate to much more than 1 second. You don't even need to use an RTC interrupt. Software can come to the rescue of dimly built hardware. Basically, your sofware loops as tightly as possible, reading the RTC, and notice when it increments. It will take you a maximum of 1 second of tight polling to do that. Then you have captured the tick as accurately as the frequency with which you can query the RTC (many thousands of times per second). (There are complications if running multi-threaded when your polling loop might be interrupted by other tasks, which you must take care to account for the possibility of.) If you don't want to dedicate a core or a bus to a continuous 1-second loop, and you already have a higher-resolution timer in the system (as in a modern PC Linux system), you can do this just as well over a few seconds, with much lower (largely invisible) overhead. Poll the RTC once, delay your polling process by a tenth of a second (as measured by your higher resolution timer -- letting other tasks run during that time), then poll it again. Loop on that. When you see it has incremented, then you know (within your process scheduling latency + 1/10th second) the phase of when it ticked. Now schedule a delay until a tenth of a second before you think it will next tick. After the delay, do the high-speed loop reading the RTC and waiting for it to tick; that should only take you 1/10th of a second of dedicating polling. You can insert a middle phase in which you do e.g. .01 second delays in order to creep up on when you believe it will tick. What you want is to have your tight loop start running JUST BEFORE you think the RTC will tick, so it will read the old value, then only spin perhaps a few dozen or few hundred times, before it sees an accurately caught tick. Then NTP can condition your high resolution (but volatile and drifty) clock based on the recent tick. You're done. You can do this at whatever frequency you like to measure the drift between the HR time and the RTC. John Gilmore -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected]. -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
Again perhaps you should tell use what it is you are really trying to do. You seemed to intimate that you have and external RTC. Not suree what that is, but why not replace it with and expernal GPS clock instead. Or is this supposed to be operating at the bottom of the ocean? If you sync rtc from the system clock, why not just use the system clock freerunning? Not at all clear why you want to go via the rtc since it can only be queried to the nearest second anyway. But giving us more details of what you are trying to do might alloow us to make better suggestions than we can now. On Mon, 31 Mar 2025, Ahmad Fatoum wrote: [CAUTION: Non-UBC Email] Hello Miroslav, Thanks for your feedback. On 3/25/25 14:46, Miroslav Lichvar wrote: On Mon, Mar 24, 2025 at 04:26:31PM +0100, Ahmad Fatoum wrote: [snip] - 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 This looks like a significant complication. I prefer to keeps things simple if possible, avoiding fallbacks and switching between different modes of operation. I am open to less complicated ways to achieve this that don't require us to restart chrony with different configs. Have you considered using the local option for the RTC refclock? I was not aware for it and will try it out. I.e. use it only for stabilization of the system clock, not as a time source. That would work even when it's synchronizing to NTP servers. When NTP is not reachable, it would activate the local reference as configured by the local directive. I guess something would be needed for the case when it's started without NTP. Do you have a suggestion how to go about it? I also think that even if local works for us, we still need to address the synchronization of the RTC to system time when the system is NTP-synchronized. Currently, chrony disallows rtc reference clock to co-exist with rtcsync, but maybe we should allow it and enable the rtcsync only when NTP is reachable and the RTC is local and not activated? Thanks, Ahmad -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected]. -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
On Mon, Mar 24, 2025 at 04:26:31PM +0100, Ahmad Fatoum wrote: > - 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 This looks like a significant complication. I prefer to keeps things simple if possible, avoiding fallbacks and switching between different modes of operation. Have you considered using the local option for the RTC refclock? I.e. use it only for stabilization of the system clock, not as a time source. That would work even when it's synchronizing to NTP servers. When NTP is not reachable, it would activate the local reference as configured by the local directive. I guess something would be needed for the case when it's started without NTP. -- Miroslav Lichvar -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
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 |_ [email protected] > 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 |_ >> [email protected] >> 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 [email protected] with >>> "unsubscribe" in the subject. >>> For help email [email protected] with "help" >>> in the >>> subject. >>> Trouble? Email [email protected]. >>> >>> >> >> -- >> To unsubscribe email [email protected] with >> "unsubscribe
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
I wastalking about giving the system clocks temperature compensation. Ie, use a thermometer on the motherboard (near the onboard clock if possible) What accuracy do you need? What are lengths of the times that the systerm have no communication with outside refclocks? Is it more imporant that the clocks be synchronized to each other, or that their clocks accuratly follow UTC? 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 |_ [email protected] 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 |_ [email protected] 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 [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email list
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
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. 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. 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 |_ [email protected] 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 |_ [email protected] 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 [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected]. -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected]. -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
Re: [chrony-dev] [RFC] Transparent fallback from NTP reference clock to RTC
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 |_ [email protected] 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 [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected]. -- To unsubscribe email [email protected] with "unsubscribe" in the subject. For help email [email protected] with "help" in the subject. Trouble? Email [email protected].
