On Fri, Nov 17, 2023 at 01:41:19AM +0100, Andrew Zaborowski wrote:
> On Thu, 16 Nov 2023 at 23:46, Richard Cochran <richardcoch...@gmail.com> 
> wrote:
> > 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?

Ah, yes, you are right.  Even simpler!

> Do you want to require the user to enforce that the port numbering is
> the same between the ptp4l processes?

No.

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

The clockIdentity is not exposed, so what do you mean by "compliance"?

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

That is just par for the course.  I'm not the one making up tons of
crazy new options.

The strength of linuxptp is modularity and fine grained, configurable
options.  This means that a) ptp4l works even with equipment that
fails to follow the standards and/or profiles, and b) ptp4l can be
really hard to configure.

> So one solution would be to let the user configure a custom portNumber
> under port settings.

Port numbers start with 1 and increase in the order of the configured
interfaces.  If it really is required for CMLDS ports to have
*different* numbers than the normal ports, we can add a "port index
offset" option that would start the numbering at some given value.

Thanks,
Richard


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

Reply via email to