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 <asubraman...@altiostar.com> Cc: Miroslav Lichvar <mlich...@redhat.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) 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 11, 2021 at 02:16:04PM +0000, 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 >> FAULT occurs with the default value of sanity_freq_limit (which is >> 200000000). Ah! Now we are getting somewhere! This is a bug in the sanity check. I've seen it, too. Let's fix the bug. >> Modifying the configuration with --sanity_freq_limit=0 will prevent >> the FAULT from occurring , but it will not address the root cause of >> BMCA getting triggered continuously even though there is no change in >> successive announce messages in the port. No, running the BMCA is not the root cause. It is perfectly harmless to run the BMCA with the same inputs and get the same result. In fact, the 1588 standard specifies doing exactly this, over and over again. 9.2.6.8 STATE_DECISION_EVENT ... The STATE_DECISION_EVENT shall: - Logically occur simultaneously on all ports of a clock - Occur at least once per Announce message transmission interval IEEE Std 1588-2008, page 81 The linuxptp implement does not follow this directive all the time, because the BMCA has no time component. If the inputs have not changed, then the output remains the same. But you see that re-running the BMCA is harmless and not a bug. > Point noted. > When we increase sanity_freq_limit to a higher value or disable, we are not > seeing the issue of flap between UNCALIBRATED and SLAVE state. How was this > default limit decided?. > When BMCA is triggered continuously we still see below issues: > 1. The log "ptp4l[1205111.854]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE ptp4l[1205111.857]: selected best master clock 000000.0000.000005" is printed continously. > 2. The log "port 1: master state recommended in slave only mode ptp4l[1205469.356]: port 1: defaultDS.priority1 probably misconfigured" is printed continuously. > We need to rate limit the 1st log as it will be printed whenever BMCA is > triggered and we need to avoid log 2 when boundary_clock_jbod=1 and > clientOnly=1 Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
