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

[ Thread Index | Date Index | More chrony.tuxfamily.org/chrony-dev Archives ]


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


Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/