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.

When an announce receipt timeout between two successive calls of
clock_check_sample, the mono interval increases to a higher value.
We might need to move the part where the monotonic time is taken outside of
the function such that the interval becomes independent of when the
function is called.

I don't think we have an option to obtain the monotonic timestamp when the
packet is received(Similar to how SW/HW timestamps are received). I feel
Moving it anywhere else in the ptp4l code will still make it dependent on
when it is executed.

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

Reply via email to