Hi Miroslav Lichvar,
Please find our comments inline.
Thanks,
Amar B S
> -Original Message-
> From: Miroslav Lichvar [mailto:mlich...@redhat.com]
> Sent: 20 May 2021 18:43
> To: Amar Subramanyam
> Cc: linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] [PATCH] Sync
On Mon, May 17, 2021 at 10:02:59AM +0300, Amar Subramanyam via Linuxptp-devel
wrote:
> This patch addresses the following issues when ptp4l is run on multiple ports
> with jbod and client only mode (i.e. clientOnly=1 and boundary_clock_jbod=1):-
>
> 1.The LISTENING port prints continuously
This patch addresses the following issues when ptp4l is run on multiple ports
with jbod and client only mode (i.e. clientOnly=1 and boundary_clock_jbod=1):-
1.The LISTENING port prints continuously
"selected best master clock 00..03
updating UTC offset to 37"
On Wed, May 12, 2021 at 10:28:34AM +0200, Miroslav Lichvar wrote:
> I think the fix should be one of the following:
> - disable clock check in jbod mode (it cannot work reliably as it is)
> - limit the check to timestamps from the synchronized port
This sounds like the best choice to me.
> -
On Wed, May 12, 2021 at 10:57:24AM +, Amar Subramanyam wrote:
> Should we rate limit log (a) as it will be printed whenever BMCA is triggered
> and avoid log (b) when boundary_clock_jbod=1 and clientOnly=1
Sounds reasonable to me.
Thanks,
Richard
Hi Richard,
Kindly discard the previous reply. Please find our response inline.
Thanks,
Amar B S
-Original Message-
From: Richard Cochran [mailto:richardcoch...@gmail.com]
Sent: 11 May 2021 21:01
To: Amar Subramanyam
Cc: Miroslav Lichvar ; linuxptp-devel@lists.sourceforge.net
On Tue, May 11, 2021 at 02:16:04PM +, Amar Subramanyam wrote:
> What happens here exactly is, due to the continuous triggering of BMCA, the
> value of mono_interval (the interval between two successive calls of
> clock_check_sample ()) gets increased and SYNCRONIZATION FAULT occurs with
>
Hi Ramana,
Please find our response inline. Let us know if any changes are required.
Thanks
Amar B S
-Original Message-
From: Richard Cochran [mailto:richardcoch...@gmail.com]
Sent: 11 May 2021 21:01
To: Amar Subramanyam
Cc: Miroslav Lichvar ; linuxptp-devel@lists.sourceforge.net
On Tue, May 11, 2021 at 02:16:04PM +, Amar Subramanyam via Linuxptp-devel
wrote:
> What happens here exactly is, due to the continuous triggering of
> BMCA, the value of mono_interval (the interval between two
> successive calls of clock_check_sample ()) gets increased and
> SYNCRONIZATION
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
Hi Miroslav Lichvar,
Thanks for your review. Please find our comments inline.
Thanks,
Amar B S
-Original Message-
From: Miroslav Lichvar [mailto:mlich...@redhat.com]
Sent: 10 May 2021 16:58
To: Amar Subramanyam
Cc: linuxptp-devel@lists.sourceforge.net; Ramana Reddy ;
Karthikkumar
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
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,
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
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
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
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
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] [PATCH] Sync issues observed when
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
Hi,
The commands we used for testing below issues are:
For 8275.1 profile:
ptp4l -f config_ptp_8275_1.conf -i sriov1 -i sriov0 -H -m 2 --boundary_clock=1
--slaveOnly=1
phc2sys -a -r -m -R 16 -n 24
For 8275.2 profile:
ptp4l -f config_ptp_8275_2.conf -i sriov1 -i sriov0 -H -m 4
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
20 matches
Mail list logo
