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.
Thanks,
Richard
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
