Hi Richard and Miroslav, I can imagine that allowing an Announce messages on the UDS port and > letting the UDS port participate in BMCA might make the whole system > easier to understand/configure. > > For this we would need: > > - proper BMCA logic in phc2sys and ts2phc > > - configuration of relevant management attributes in phc2sys and > ts2phc > Yes, we also came up with this design by sending Announce message with UDS as it’s easy to understand and vPort behaves the same as other ports. Currently, in this approach, only TS2PHC is participating in the PTP4L BMCA as per the standard requirements. We do agree we can have reverse communication for PTP4L to communicate with TS2PHC and participate in BMCA logic running in TS2PHC or PHC2SYS, which is not implemented in the current check-in. Another approach could be to keep the BMCA only in PTP4L and implement a mechanism to notify the TS2PHC and PHC2SYS about the selected timing source. The reverse mechanism is out of the scope of this checkin but we are ready to take it up and implement based on your inputs. [image: image.png]
I suspect I'd find it more confusing. UDS is intended for monitoring > and management. It is not a port of the clock that can be used for > synchronization. A hardware clock cannot timestamp UDS messages. > Yes, the hardware clock cannot timestamp the UDS messages. The reason we came up with a separate vPort implementation with UDS, for the time being, was to make it easy to understand and in future, if required we can make the necessary changes in the transport mechanism, this would have addressed your concerns. But as Richard has suggested keeping the same UDS file to avoid redundant code. We can see in the future how to enhance and use the mechanism you have suggested. Multiple translations working at the same time? On the same clock? In this case, IWF clocks will be running in freerun mode. This is basically acting as a gateway for profile translation and not for configuring the PHC. The implementation can be explained by the below diagram: [image: image.png] So far LinuxPTP doesn’t have Virtual port implementation in a real sense, this approach gives standard implementation which is easier to understand. Also, transport mechanisms can be enhanced based on future requirements. Thanks, SyncMonk Technologies. On Mon, 5 Sept 2022 at 20:52, Miroslav Lichvar <mlich...@redhat.com> wrote: > On Mon, Sep 05, 2022 at 07:20:49AM -0700, Richard Cochran wrote: > > I can imagine that allowing an Announce messages on the UDS port and > > letting the UDS port participate in BMCA might make the whole system > > easier to understand/configure. > > I suspect I'd find it more confusing. UDS is intended for monitoring > and management. It is not a port of the clock that can be used for > synchronization. A hardware clock cannot timestamp UDS messages. > > In the jbod mode there are multiple hardware clocks. I don't see how > would phc2sys work only with announce messages. > > > For this we would need: > > > > - proper BMCA logic in phc2sys and ts2phc > > Turning the system clock (phc2sys) and reference clock (ts2phc) into a > virtual PTP clock? > > I like the idea of reusing PTP for synchronization to/from the system > clock, and I think I already proposed it some time ago, but it would need > ptp4l to be combined with phc2sys in order to create a true virtual > network where timestamping of sync and delay_req messages can provide > the same level of accuracy (i.e. sharing the timestamps from the > SYS_OFFSET ioctl). > > -- > Miroslav Lichvar > > > > _______________________________________________ > Linuxptp-devel mailing list > Linuxptp-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/linuxptp-devel >
_______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
