Re: [Linuxptp-users] [issue] phc2sys results large jitter with multiple '-c'

[Keller, J. E <jac...@in...>]

> -----Original Message-----
> From: Miroslav Lichvar <mli...@re...>
> Sent: Wednesday, June 21, 2023 12:52 AM
> To: Keller, Jacob E <jac...@in...>
> Cc: lin...@li...
> Subject: Re: [Linuxptp-users] [issue] phc2sys results large jitter with multiple '-c'
> 
> On Tue, Jun 20, 2023 at 10:07:14PM -0700, Jacob Keller wrote:
> > On 6/11/2023 11:53 PM, Miroslav Lichvar wrote:
> > > If you need to synchronize multiple PHCs to each other, it's better to
> > > use one phc2sys instance to synchronize the system clock to the source
> > > PHC and then another phc2sys instance to synchronize the rest of PHCs
> > > to the system clock.
> > >
> >
> > In theory the kernel could be extended with an interface to perform the
> > comparison between two clocks in-kernel without a switch. That would be
> > a bit better than doing it in user space.
> 
> The drivers could provide a callback for other drivers to read the
> lowest part of the timestamp and another callback to complete the
> timestamp. One issue with this approach would be increased delay due
> to the measurement doing 3 PCIe reads instead of 1 PCIe read and
> 2 system clock reads. Another issue might with hardware which cannot
> read the lowest part of the timestamp (latching) twice without reading
> the rest, if such a thing exists.
> 
> A better approach would be to use the system clock as a reference,
> similarly to what you described for PTM, except doing it multiple
> times in the style of PTP_SYS_OFFSET_EXTENDED with interleaved
> readings SYS, PHC1, SYS, PHC2, SYS, PHC1, SYS ... and combining the
> measurements in the kernel or user space.
> 
> --
> Miroslav Lichvar

Ya that would work. I don't know if there is sufficient demand to add such an interface though.

Thanks,
Jake