Again, I'm not arguing there is no interface between synce4l and ptp4l; but the development of synce4l, which is a implementation of the ITU-T G.8264 ESMC protocol and interfaces the synchronous Ethernet Equipment Clock (EEC), should not be under the linuxptp project, which is an implementation of the IEEE 1588 protocol which interfaces the Local PTP Clock (via the Linux PHC).
Below is a snip from the Network Time Foundation: The Linux PTP Project is a Linux-focused software implementation of the Precision Time Protocol (PTP) specification that meets or exceeds the IEEE 1588 Standard. Its dual design goals are to provide the highest possible performance levels and be a thoroughly robust implementation of the PTP Standard. Thus, I would be more supportive of get NTF to start a Linux ESMC Project (synce4l) and allow your submission to be there. This will also make sure one does not "break" either protocol to support L1 syntonization in PTP (i.e. make sure the interfaces are vetted properly, and that there is no undesired influences on either clock by the other protocol). Greg -----Original Message----- From: Kubalewski, Arkadiusz <arkadiusz.kubalew...@intel.com> Sent: June 1, 2022 10:44 AM To: Greg Armstrong <greg.armstrong...@renesas.com>; Miroslav Lichvar <mlich...@redhat.com> Cc: Kwapulinski, Piotr <piotr.kwapulin...@intel.com>; Sawula, Andrzej <andrzej.saw...@intel.com>; linuxptp-devel@lists.sourceforge.net; Gerasymenko, Anatolii <anatolii.gerasyme...@intel.com> Subject: RE: [Linuxptp-devel] [PATCH 00/11] synce4l: add software for Synchronous Ethernet -----Original Message----- From: Greg Armstrong <greg.armstrong...@renesas.com> Sent: Wednesday, June 1, 2022 3:18 PM > > 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. > > 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). According to the Annex L, L.1 General, L1Sync is optional feature that can be used to support cooperation between PTP and physical layer (L1) based syntonization, also example of Synchronous Ethernet is given. My understanding: First there must be physical layer (L1) based synchronization, then PTP protocol can support L1Sync. Or in other words, the one will not be able to support optional PTP L1Sync, without physical layer (L1) based syntonization (e.g. SyncE) Am I wrong somewhere? Thanks, Arkadiusz > > 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). > > Greg > > Greg Armstrong > Principal System Architect, Timing Products Division Renesas > Electronics Canada Limited > Mobile: 1-613-218-9373 > > -----Original Message----- > From: Miroslav Lichvar <mlich...@redhat.com> > Sent: June 1, 2022 3:33 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 Tue, May 31, 2022 at 02:42:00PM +0000, Greg Armstrong wrote: > > This is the reason synce4l (based on an ITU-T physical layer protocol, > > G.8264) should be separate from linuxptp project and be it's own standalone > > project; so that it does NOT get confused with L1_SYNC TLV from IEEE > > 1588-2019 (if/when it gets added to linuxptp). The HA profile's use of the > > physical layer clock is not the same as ITU-T definition of SyncE. > > If synce4l remained specific to G.8264, the confusion could be avoided > by renaming it to something else. (I don't have a suggestion at the > moment.) > > There are plenty of conflicting options in linuxptp. > > The advantage of having both supported in linuxptp, no matter if the actual > HW support is for both in synce4l or separately in ptp4l and synce4l, is that > the support code can be shared. The difference in the protocol (L1_SYNC TLV > vs SSM) seems to me quite small when compared to the rest. > > -- > Miroslav Lichvar > > > _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
