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

[Miroslav Lichvar <mlichvar@xxxxxxxxxx>]

Sorry for late response.

On Sat, Dec 13, 2025 at 02:41:01AM +0000, Hall, Christopher S wrote:
> > 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?

Yes, or SCM_TIMESTAMPING.

> 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

As I understand it, the difficulty in implementing a selectable SW
timestamping clock is that the clock will not be known at the time
when the timestamp is captured. The timestamp would probably need to
be always captured by CLOCK_MONOTONIC_RAW. There is no space in skb to
save SW timestamps from multiple clocks. Only later, when the packet
is assigned to a socket the timestamp can be converted to the selected
clock. The problem is that there can be multiple frequency and/or
phase adjustments of the clock between the time of capture and
conversion, so the adjustments would need to be tracked and reapplied
to the timestamp, as if it was captured by 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.
> 
> 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?

There is an old hack that replaces the system clock with a single PHC:
https://www.mail-archive.com/chrony-users@xxxxxxxxxxxxxxxxxxxx/msg01881.html

That's not the right direction.

What I'd like to see is a new directive that specifies a list of
clocks that should be synchronized, e.g. CLOCK_REALTIME, CLOCK_AUX*,
/dev/ptp*. It could be empty to use only CLOCK_MONOTONIC_RAW and be
able to serve time, but not touching any clocks.

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

The current phc2sys code can work with multiple ptp4l instances
(specified by multiple -z options) and select between them. The
current selection is very simple, it's the first acceptable source in
the order they were specified, but that could be improved.

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