Re: [Linuxptp-devel] [PATCH] Sync issues observed when ptp4l is ran with jbod and client only mode (clientOnly=1 and boundary_clock_jbod=1)
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 Sent: May 10, 2021 7:58 AM To: Greg Armstrong Cc: Amar Subramanyam ; 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 +, 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
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 +, 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
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 11:37:06AM +, Amar Subramanyam wrote: > Continuous BMCA triggering in port 2 causes a SYNCHRONIZATION FAULT in > port1.This causes port1 to jump from SLAVE to UNCALIBRATED and vice versa > repeatedly. I'm sorry if I sound like a broken record, but what exactly is the cause of the fault? Is it the clock check seeing timestamps from two clocks that are not synchronized? Do the faults disappear if you set --sanity_freq_limit=0? That's the only fault I see in my test and in your original report. Your patch doesn't seem to prevent that fault in my test, so I'm confused. > Noted. Please find the updated description and function name below, we will > send out the modified patch after full review. > > + * Get port SLAVE state for client only mode. > + * @param c The clock instance. > + * @return Return 0 if any port is in SLAVE state, 1 otherwise. > + */ > +int clock_get_port_slave_state(struct clock *c); There might be a better name for this function. Maybe something related to its purpose rather than what it does. > Hence, we are clearing the Announce receipt timer for port2 (LISTENING port) > in the function bc_event() upon Announce receipt timeout, only when > boundary_clock_jbod=1 and clientOnly=1 is configured and atleast one port > (Port1 here) is in SLAVE/UNCALIBRATED state. Ok, but if this optimization is useful in the jbod mode, it should be useful even in the non-jbod mode, right? Most of the port code shouldn't care about jbod. -- Miroslav Lichvar ___ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
