RE: [chrony-dev] [RFC PATCH v1 00/17] RFC: Patch enabling support for Linux auxiliary clocks

["Hall, Christopher S" <christopher.s.hall@xxxxxxxxx>]

Hi Miroslav,

> On Sat, Dec 06, 2025 at 06:10:46AM +0000, Christopher S M Hall wrote:
> > This patchset enables use of auxiliary clocks with Chrony. Support for
> 
> My plan was to add auxiliary clocks when sockets can have the SW
> timestamping clock selected (not easy, but should be possible with
> tracking of phase+frequency changes between the different clocks in
> a ring buffer and reconstructing the offset in the history of the
> selected clock).

Are you referring to the SW timestamps from SCM_TIMESTAMP and SCM_TIMESTAMPNS?
I may be misunderstanding your idea, but my idea was to "bind" to a clock
at the socket level. We have an API to read the auxclock in the kernel. Wouldn't an
approach be:

replace ktime_get_real() with ktime_get_clock_ts64 in __net_timestamps()
add an additional argument to that internal function
add an additional field for a clock ID in the sock structure

there may be an additional complication of adding entirely new timestamping
socket options as well.

I would be concerned - assuming I'm understanding - that the ring buffer
approach may not be very precise.  

> There is also an older plan to support synchronization of PHCs, so the
> new configuration and code should be general enough to cover both PHCs
> and AUX clocks.

What would this look like in terms of interface? Do we add a PHC to PHC mode
that does not set CLOCK_REALTIME? Is there any code written for this approach
that I can look at?

> Ideally, I'd like to isolate chronyd from the adjustable system clocks
> and keep its NTP clock running on top of CLOCK_MONOTONIC_RAW, so if
> anything is interfering with the system clocks it won't disturb the
> chronyd loop. Some people seem to like running an NTP server in a
> container and synchronizing the system clock to it, however bad idea
> that is with the current design.
> 
> There is a complication with timers. CLOCK_REALTIME/MONOTONIC running
> at a different rate than the synchronized clock may impact chronyd
> behavior. A compensation might be needed in some instances.
> 
> I'll need to think about this more.

> > The patchset also adds a 'nooffsetsanitycheck' directive,
> > taking no options, that disables offset sanity checking because there
> > is no expectation that a local auxiliary clock is related to UTC/TAI.
> 
> Disabling the sanity checks completely is not acceptable with the
> current code. As a workaround, you can set the --with-ntp-era=0
> configure option to allow synchronization near zero. With NTPv5 we
> might need to extend the covered time interval, but I suspect that
> will require some significant changes in the code.

I'm not sure I understand. I'm not sure if you saw the code, but I only
disabled the sanity check in UTI_IsTimeOffsetSane() and that
can probably be done with finer precision if needed. I'm not seeing
what this breaks especially since it is off by default.

> > its own vclock that is disciplined by PTP. Two instances of PTP4L
> > discipline their respective vclocks and two instances of Chrony
> > transfer time from the vclock to CLOCK_REALTIME or an auxiliary clock
> > using the vclock PHC API.
> 
> Hm, so there is no NTP involved

The use case we're after is industrial automation which will require
backup time sources. Some users want to use NTP as the backup.

> and just a single refclock for each instance.

We need at least one backup clock either NTP or PTP depending on
the specific application requirements

> Users are asking for it. BTW, the current phc2sys code already
> supports multiple sources as a fallback mechanism.

I'm aware of the '-a' flag that follows the BMCA result from PTP4L.
This could be adapted, but as far as I know uses a single domain and
a single PTP4L instance. The primary and secondary PTP clocks for our
use would use separate domains and PTP4L instances. Are there requests
for redundant clocks on the Linux PTP mailing list? I would be happy to
try that angle if Richard supports it. He may have changed his mind, but
in the past he has said that he doesn't want to add any new functionality
PHC2SYS.

> Miroslav Lichvar

Thanks,
Christopher

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