It may not break anything at the protocol, but I suspect the state decision algorithm is what's breaking. By setting clientOnly, you don't allow any PTP port to enter the MASTER (or PASSIVE) state (see IEEE1588-2019 Figure 31 for slave-only state machine). However, a BC would normally put any PTP port that is not SLAVE/UNCALIBRATED into the MASTER/PRE_MASTER or PASSIVE state - these are not allowed in slave-only.
I suspect this is why LISTENING is used by the 2nd PTP port (when the 1st PTP port is in the SLAVE state). However, once the Announce is received by the 2nd GM, the local PTP port needed to change to UNCALIBRATED state. From this state, the only allowed transition is to SLAVE state - and this is likely what breaks as there is already a port in the SLAVE state. I have not dwelled into ptp4l state machine, but suspect this causes all the PTP ports to enter FAULTY state. This would explain what was observed of toggling in/out of FAULTY state. Greg -----Original Message----- From: Miroslav Lichvar <mlich...@redhat.com> Sent: May 10, 2021 7:58 AM To: Greg Armstrong <greg.armstrong...@renesas.com> Cc: Amar Subramanyam <asubraman...@altiostar.com>; linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Sync issues observed when ptp4l is ran with jbod and client only mode (clientOnly=1 and boundary_clock_jbod=1) On Fri, May 07, 2021 at 02:27:46PM +0000, Greg Armstrong wrote: > Just to add, the key reason it is not supported by BC is that if true, then > clockClass must be 255. This clockClass is only for slave-only OC. > > From IEEE1588-2019 clause 8.2.1.3.1.2: > If defaultDS.slaveOnly is TRUE, the initialization value [of > defaultDS.clockQuality.clockClass] shall be 255 as specified in 7.6.2.5. > > From IEEE1588-2019 Table 4: > 255 | Shall be the clockClass of a slave-only PTP Instance > (see 9.2.2.1). > > And clause 9.2.2.1 title is "Slave-Only Ordinary Clocks". Good point. But this doesn't break anything at the protocol level, right? A slaveOnly clock should never send an annoucement message with its clockClass. It is an extension that we can support in linuxptp, assuming we can make it work as expected, e.g. avoid those "priority1 probably misconfigured" warnings, etc. -- Miroslav Lichvar _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
