I see synce4l as an implementation of the ESMC protocol, thus, the name fits. As you highlighted, there will be challenges for synce4l to configure and monitor the L1 properties of the hardware, and also interface the EEC hardware.
If this wasn't the intent of synce4l, then I agree, the name needs to change to remove "synce", which is an ITU-T term. For the implementation of L1_SYNC, it may or may not have the same interfaces to hardware - especially when looking at how HA profile uses it. Also, the ITU-T 1588 profiles do not use L1_SYNC to manage the physical layer - I'm only aware of the HA profile using it right now. Greg -----Original Message----- From: Miroslav Lichvar <mlich...@redhat.com> Sent: June 1, 2022 11:19 AM To: Greg Armstrong <greg.armstrong...@renesas.com> Cc: Richard Cochran <richardcoch...@gmail.com>; piotr.kwapulin...@intel.com; anatolii.gerasyme...@intel.com; andrzej.saw...@intel.com; linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet On Wed, Jun 01, 2022 at 01:18:09PM +0000, Greg Armstrong wrote: > > The difference in the protocol (L1_SYNC TLV vs SSM) seems to me quite small > > when compared to the rest. > > This is my concern, as this statement is false. SyncE describes an ITU-T > network synchronization method for the distribution of frequency over a > transport network, using the L1 physical layer clock (Ethernet or OTN). > Details of the network limits, equipment clock requirements, protocol and > architecture are contained in numerous ITU-T recommendations (G.826x). The > use of the SyncE clock to assist PTP is described in G.8273.2 for T-BC/T-TSC > (and also in G.8273.4 as a option for T-BC-P/T-TSC-P). In this case, the > SyncE clock does not need to be coherent or congruent with the PTP clock. > > The L1_SYNC TLV is a Layer-1 based synchronization performance enhancement > for PTP (described in Annex L of IEEE 1588-2019). The key aspect of the > scheme illustrated by the high accuracy model is that the physical clock > signal and the time of the PTP Instance are coherent. The HA profile (corresponding to White Rabbit) requires that, but not the L1 support in PTP in general. That's the point of the L1_SYNC TLV to communicate the requirements for coherency and congruency between the peers. > Yes, both methods can be used to syntonize the Timestamping Clocks in all PTP > Instances to within the required tolerance with respect to the Grandmaster > Clock, but how to use SyncE vs L1_SYNC in the protocol (ptp4l) is different - > one is managed with the protocol (L1_SYNC) the other by it's own protocol > (synce4l). Right. But consider what the L1 support is in essence. The main point is to configure and monitor the L1 properties of the hardware. A proper kernel interface doesn't exist yet. It might be ethtool netlink, which is not very easy to use (at least for me). > I'm not arguing there could not be shared support code, but to the uninformed > developer, synce4l could be mistaken for L1_SYNC (i.e. mistakenly use the PHC > for "SyncE" clock management). Also, as Richard highlighted, the development > of synce4l and ptp4l are mutual exclusive, so it does not make sense for the > synce4l code submissions to be reviewed by the linuxptp development > community, as they are not the right audience (as unlikely familiar with the > ITU-T recommendations that synce4l must follow). As I said, the confusion could be avoided by different naming if necessary. To me that doesn't look like a big concern. linuxptp includes utilities like phc2sys and phc_ctl that don't have much to do with the PTP protocol, but they are useful when PTP is used for synchronization. Same applies to synce4l. There already is support for some telco profiles, so I'd say it's a very good fit for the project. Whether Richard has or doesn't have time to review/maintain the code, I think that is a different matter. -- Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
