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 <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. We can look at fixing the issue with sanity freq limit. But no clue as why and how this sanity_freq_limit default value has been Arrived at. Probably if we propose to disable this sanity freq limit by default or increasing this to much higher value as default might be one of the ways that can be thought through. However we still need to address below issues: (a). ptp4l keep logging below best master clock messages (selected best master clock 000000.0000.000003) continuously flooding the logfile: (b). The inactive LISTENING port continuously prints an error (master state recommended in slave only mode) which seems to be related to boundary clock but not for Ordinary Clock Subordinate/Slave. Logs: ptp4l[755639.589]: rms 5 max 7 freq -877 +/- 6 delay 25476 +/- 0 ptp4l[755639.818]: selected best master clock 000000.0000.000003 ptp4l[755639.818]: updating UTC offset to 37 ptp4l[755639.818]: port 2: master state recommended in slave only mode ptp4l[755639.818]: port 2: defaultDS.priority1 probably misconfigured ptp4l[755639.990]: selected best master clock 000000.0000.000003 ptp4l[755639.990]: updating UTC offset to 37 ptp4l[755640.193]: selected best master clock 000000.0000.000003 ptp4l[755640.193]: updating UTC offset to 37 ptp4l[755640.193]: port 2: master state recommended in slave only mode ptp4l[755640.193]: port 2: defaultDS.priority1 probably misconfigured ptp4l[755640.385]: selected best master clock 000000.0000.000003 ptp4l[755640.385]: updating UTC offset to 37 ptp4l[755640.568]: rms 4 max 8 freq -877 +/- 6 delay 25476 +/- 0 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 > Thanks, > Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
