On Mon, Oct 17, 2022 at 09:14:14PM +0200, Erez wrote: > On Mon, 17 Oct 2022 at 16:46, Vipin Sharma <vipin.sha...@syncmonk.net> > wrote: > > > Hi Richard, > > We really appreciate the work and time you have spent on our commits and > > the community work you are doing for LinuxPTP and other timesync features. > > > > "I read Annex B and Appendix III of T-REC-G.8275-202010, and I claim > > > > that linuxptp already implements this functionality, even though there is > >> no "virtual port" explicitly modeled." > > > > > > I see that you have said that this functionality is already present and > > it's against the design practice for having the same thing in two different > > ways. We have the opinion that LinuxPTP doesn't support the Virtual Port > > mechanism to address the specification. > > > > If you talk about BMCA in ts2phc or phc2sys that actually doesn't make any > > sense. Since the virtual port should participate in the ptp4l BMCA, it > > should select the best port among them, including the virtual port. > > This is actually in the right approach as ts2phc acts as a PTP node and > > sends announce and sync messages to the BMCA in PTP4L instance. There is a > > possibility of N numbers of Ports which can become master and TS2PHC or > > PHC2SYS won't be aware of it so keeping BMCA in the one place is the right > > approach. > > > > > I saw a similar complaint with the sys2phc, as it can not change the > direction of the synchronization if the port is master instead of client. > I do think you have a point. > But I think Richard is not interested in new naming of virtual ports and > moving the ts2phc into ptp4l. > I think he looks for fewer changes that would be able to support your > deployment, but without merging the ts2phc into ptp4l. > Perhaps you are right and we should merge ts2phc and sys2phc into ptp4l and > let the system clock or any non PTP clock behave as a virtual port. > But I think you should start by explicitly explaining in simple, what you > think is missing in the current ts2phc and sys2phc to fulfill your needs, > but without moving to a robust ptp4l with "virtual ports". > Or convince us, why do you think the new "virtual port" is better? > > Erez >
The missing piece in the ts2phc is the ability to export its status and some predefined dataset to the ptp4l. Now you can eihter use the ts2phc to synchronize the PHC to the timestamps and setup the ptp4l in a master-only mode to support the Grandmaster setup, or base on the ptp4l BMCA to select the right clock from the network and synchronize to it. What APTS tries to address is the situation when you can fall-back to the slave port in case your ts2phc source fails for some reason (say you lose the visibility of the sky in your GNSS receiver). To address that we need some channel between ts2phc and ptp4l. The easiest way to implement it is to use existing PMC protocol and send the correct dataset to the ptp4l whenever the PPS is correct, and change it to the lower spec when it's not. That could reuse exisitng channel recently added to ts2phc for dynamic PPS reconfiguration. Regards Maciek _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
