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

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

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

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.

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.

> auxiliary clocks is enabled at compile time using the
> 'enable-auxclock' flag. The added 'auxclockid' directive takes two
> options: 'set' and 'alloc'. Set takes one argument which is the clock
> ID of a preconfigured clock. The alloc option takes no arguments and
> dynamically allocates a clock at runtime and frees that clock on
> exit.

The alloc option and reporting the ID back doesn't seem right to me.
I'd leave it to the system admin to configure that.

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

> 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 and just a single refclock for each
instance. It might be easier to add the missing telemetry to phc2sys.
Users are asking for it. BTW, the current phc2sys code already
supports multiple sources as a fallback mechanism.

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