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

[Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx>]

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  |_ 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, 31 Mar 2025, John Gilmore wrote:
> 
>> [CAUTION: Non-UBC Email]
>>
>> Bill Unruh <unruh@xxxxxxxxxxxxxx> 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 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.