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