Re: [patch 0/3] ptp: Provide support for auxiliary clocks for PTP_SYS_OFFSET_EXTENDED

[Miroslav Lichvar <mlichvar@redhat.com>]

On Thu, Jun 26, 2025 at 03:27:28PM +0200, Thomas Gleixner wrote:
> This is obviously incomplete as the user space steering daemon needs to be
> able to correlate timestamps from these auxiliary clocks with the
> associated PTP device timestamp. The PTP_SYS_OFFSET_EXTENDED IOCTL command
> already supports to select clock IDs for pre and post hardware timestamps,
> so the first step for correlation is to extend that IOCTL to allow
> selecting auxiliary clocks.

> Miroslav: This branch should enable you to test the actual steering via a
> 	  PTP device which has PTP_SYS_OFFSET_EXTENDED support in the driver.

Nice! I ran few quick tests and it seems to be working great. The
observed delay and stability with an AUX clock synchronized to a PHC
seems to be the same as with CLOCK_REALTIME.

Are there any plans to enable software timestamping of packets by
AUX clocks? That would allow an NTP/PTP instance using SW timestamps
to be fully isolated from the adjustments of the CLOCK_REALTIME clock,
e.g. to run an independent NTP/PTP server in a container. This might
be tricky as the skb would likely need to contain the MONOTONIC_RAW
timestamp to be converted later when it gets to a socket, so some
history of adjustments of each clock would need to be saved and
reapplied to the raw timestamp.

-- 
Miroslav Lichvar