On Thu, 16 Nov 2023 at 23:46, Richard Cochran <richardcoch...@gmail.com> wrote:
> On Thu, Nov 16, 2023 at 11:11:50PM +0100, Andrew Zaborowski wrote:
> > The two timestamps are passed to clock_peer_delay() by the receiving
> > port and stored in c->tsproc.  Then they're accessed by
> > get_raw_delay() which is used in the filter logic.  I'm not sure how
> > much value that has, we can possibly pass 0s to clock_peer_delay().
>
> If the client uses CMLDS, then it doesn't need tsproc logic at all.
> It simply take the delay value from the CMLDS server.

Make sense, the CMLDS would already be filtering the timestamps once.

>
> > Regarding "source_port_index", I assume that would contain the ifindex
> > of the interface?  With virtual clocks I believe the PHC indices may
> > differ between the PTP ports on one physical port ("link port").
>
> No, I mean the PTP port number.  These are taken from the order of the
> interfaces on the command line and in the configuration file.

Won't this be the same as the UDS message's sourcePortIdentity.portNumber?

Do you want to require the user to enforce that the port numbering is
the same between the ptp4l processes?  In our use case spec compliance
is the priority, including the unique clockIdentity for CMLDS
requirement, so we'd definitely need to be running a separate ptp4l
process for CMLDS in this schema.  I'm asking because the port
numbering thing is unobvious and the user effort to configure a
compliant setup with ptp4l is already very high.

So one solution would be to let the user configure a custom portNumber
under port settings.  My colleague even had a local change to allow
passing -i <ifname>,<portNumber>.  This would also remove the
(possibly unobvious) requirement to run all ports sharing the
clockIdentity as one ptp4l process.

Another option would be to pass the ifindex as I thought you were suggesting.

Best regards


_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel

Reply via email to