One possible issue is you are setting clientOnly=1 for a BC; this is not
allowed per IEEE1588 (as a BC shall not be a slaveOnly PTP Instance).
>From IEEE1588-2019:
9.2.3 Non-slaveOnly PTP Instances
A Boundary Clock shall not be a slaveOnly PTP Instance. Ordinary Clocks
not designed or configured as slaveOnly and Boundary Clocks shall
implement the state machine illustrated in Figure 30.
>>I second that. At sometime we need to define slave_clock_jbod for
>>Ordinary_clock mode and avoid using boundary_clock_jbod with client_only
option for OC Client/Slave modes. We need to put in design and see to it that
it addresses all the aspects.
I believe present change tries to fix the existing issue with
boundary_clock_jbod with client_only config options.
Thanks,
Ramana
-----Original Message-----
From: Greg Armstrong [mailto:greg.armstrong...@renesas.com]
Sent: 07 May 2021 19:30
To: Amar Subramanyam; Miroslav Lichvar
Cc: 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)
CAUTION: This email originated from outside of Altiostar. Do not click on links
or open attachments unless you recognize the sender and you are sure the
content is safe. You will never be asked to reset your Altiostar password via
email.
One possible issue is you are setting clientOnly=1 for a BC; this is not
allowed per IEEE1588 (as a BC shall not be a slaveOnly PTP Instance).
>From IEEE1588-2019:
9.2.3 Non-slaveOnly PTP Instances
A Boundary Clock shall not be a slaveOnly PTP Instance. Ordinary Clocks
not designed or configured as slaveOnly and Boundary Clocks shall
implement the state machine illustrated in Figure 30.
Greg
-----Original Message-----
From: Amar Subramanyam via Linuxptp-devel <linuxptp-devel@lists.sourceforge.net>
Sent: May 7, 2021 7:37 AM
To: Miroslav Lichvar <mlich...@redhat.com>
Cc: 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)
Hi Miroslav,
Please find our response in line.
Thanks,
Amar B S
-----Original Message-----
From: Miroslav Lichvar [mailto:mlich...@redhat.com]
Sent: 06 May 2021 19:41
To: Amar Subramanyam <asubraman...@altiostar.com>
Cc: 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)
CAUTION: This email originated from outside of Altiostar. Do not click on links
or open attachments unless you recognize the sender and you are sure the
content is safe. You will never be asked to reset your Altiostar password via
email.
On Tue, May 04, 2021 at 01:51:24PM +0300, Amar Subramanyam via Linuxptp-devel
wrote:
> This patch addresses the following issues when ptp4l is ran on
> multiple ports with jbod and client only mode (i.e clientOnly=1 and
> boundary_clock_jbod=1):-
>
> 1.SYNCHRONIZATION FAULT occurs at every ANNOUNCE RECEIPT Timeout on
> LISTENING port, which leads to PTP port state of SLAVE port to flap
> between SLAVE and UNCALIBRATED states continuously.
>> It's not clear to me what exactly is happening here and how does the patch
>> fix it. The faults are happening due to the clock check getting out of order
>> timestamps from two unsynchronized clocks, right? Any chance it is an issue
>> with phc2sys not synchronizing the clocks?
Please find the attached diagram, which details our use case. Two active grand
masters are connected to the same Telecom Slave Clock in two different ports,
PORT1 and PORT2. Single instance of Ptp4l and phc2sys are running in the
Telecom Slave Clock with boundary_clock_jbod=1 and clientOnly=1 configurations.
The expected behaviour here is ptp4l will take into account GM1 and GM2 and
choose the best master using BMCA algorithm. The port which has the best master
will be in SLAVE state while the other port will remain in LISTENING state,
acting as a redundant port.
Let GM1 be a better master than GM2, resulting in Port1 to be in SLAVE state
and Port2 in LISTENING state. While running the latest ptp4l, we are
observing the following issues, for which we have proposed our patch :-
Since Port 2 is in LISTENING state even though we are receving announce packets
from GM2, the function add_foreign_master() is called for every Announce
message received. Here, the announce receipt timer is not re-armed and hence
will trigger BMCA for every 375ms (Default Announce reciept timeout). This is
expected behaviour for normal client only mode with only 1 port but when
multiple client/slave ports are involved(say port1, port 2), we dont expect
port 2 to trigger BMCA unless there is a change in the Announce message
recevied from GM2.
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.
Hence, we are re-arming the Announce receipt timer in the function
add_foreign_master(), only when boundary_clock_jbod=1 and clientOnly=1 is
configured and atleast one port (Port1 here) is in SLAVE/UNCALIBRATED state.
> +int clock_get_client_state(struct clock *c) +{
> + struct port *piter;
> +
> + if (!clock_slave_only(c)) {
> + return 1;
> + }
> +
> + LIST_FOREACH(piter, &c->ports, list) {
> + enum port_state ps = port_state(piter);
> + if (ps == PS_SLAVE || ps == PS_UNCALIBRATED) {
> + return 0;
> + }
> + }
> + return 1;
> +}
> + * Inform if any of the port is in SLAVE state.
> + * @param c The clock instance.
> + * @return Return 0 if any port is in SLAVE state, 1 otherwise.
> + */
> +int clock_get_client_state(struct clock *c);
>> The function seems to be specific to the slave-only mode and it checks for
>> two port states. The description and name of the function indicate something
>> else.
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);
> + * In multiport slave only mode, there maybe
> + * announce messages on LISTENING port. Re-arm
> + * the timer if any other configured port is in SLAVE state
> + */
> + if (p->jbod && !clock_get_client_state(p->clock)) {
> + port_set_announce_tmo(p);
> + }
>> Why is this and the other part of the port change specific to the jbod mode?
>> Shouldn't the announce timer work exactly the same no matter if it's a jbod
>> or a real multiport clock?
Please find the attached diagram, which details our use case. Two active grand
masters are connected to the same Telecom Slave Clock in two different ports,
PORT1 and PORT2. Single instance of Ptp4l and phc2sys are running in the
Telecom Slave Clock with boundary_clock_jbod=1 and clientOnly=1 configurations.
Let GM1 be a better master than GM2, resulting in Port1 to be in SLAVE state
and Port2 in LISTENING state.
When GM2 connection is lost or Announce messages are not received on port 2
(LISTENING port) , state decision event (BMCA algorithm) will be triggered. But
since the Port1 (SLAVE port) is still receiving the packets we dont expect to
trigger BMCA.
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.
--
Miroslav Lichvar
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
