Hi Miroslav, I am afraid, the patches that was intended to fix the reported issue doesn't do so. The issue that we reported was not due to timestamps from non-slave port being compared in jbod mode. But due to mono_interval (CLOCK_MONOTIC interval b/w two successive calls to clock_check_sample()) becoming high due to the execution BMCA algorithm between two successive calls to clock_check_sample() function. We believe that this is due to execution time being higher, and solution is to increase the default value of sanity_freq_limit accordingly. Please find the logs we collected with your patches applied. Here we can see that mono_interval (132256969) increases when compared to the interval between hardware timestamp of successive sync packets (102726564). Please note that port2(sriov1) is the current active port, and clock check is never done on port1.
Log: ptp4l[13295.936]: selected best master clock 001122.fffe.33f801 ptp4l[13295.936]: updating UTC offset to 37 ptp4l[13295.936]: port :: port 2 (sriov1) ptp4l[13295.936]: Mono Interval :: 132256969 ptp4l[13295.936]: Interval :: 102726564 ptp4l[13295.936]: clockcheck: clock jumped backward or running slower than expected! ptp4l[13295.936]: port 2 (sriov1): SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT ptp4l[13296.202]: selected best master clock 001122.fffe.33f801 ptp4l[13296.202]: updating UTC offset to 37 ptp4l[13296.319]: selected best master clock 001122.fffe.33f801 ptp4l[13296.319]: updating UTC offset to 37 ptp4l[13296.515]: selected best master clock 001122.fffe.33f801 ptp4l[13296.515]: updating UTC offset to 37 ptp4l[13296.725]: selected best master clock 001122.fffe.33f801 ptp4l[13296.725]: updating UTC offset to 37 ptp4l[13296.873]: port 2 (sriov1): UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[13296.963]: port :: port 2 (sriov1) ptp4l[13296.964]: Mono Interval :: 1027848806 ptp4l[13296.964]: Interval :: 1057330889 ptp4l[13297.013]: selected best master clock 001122.fffe.33f801 ptp4l[13297.013]: updating UTC offset to 37 ptp4l[13297.059]: port :: port 2 (sriov1) ptp4l[13297.062]: rms 8 max 14 freq -2600 +/- 9 delay 729 +/- 0 Commands used : ptp4l -f ~/config_ptp_8275_1.conf -H -m -s --boundary_clock_jbod=1 -i sriov0 -i sriov1 phc2sys -a -r -m -R 16 -n 24 Thanks, Amar B S > -----Original Message----- > From: Miroslav Lichvar [mailto:mlich...@redhat.com] > Sent: 26 May 2021 13:54 > To: linuxptp-devel@lists.sourceforge.net > Cc: Amar Subramanyam <asubraman...@altiostar.com> > Subject: [PATCH v2 3/3] port: Don't check timestamps from non-slave ports. > > 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. > > > Don't perform the sanity check on receive timestamps from ports in non-slave > states to avoid false positives in the jbod mode, where the timestamps can be > generated by different clocks. > > Reported-by: Amar Subramanyam <asubraman...@altiostar.com> > Signed-off-by: Miroslav Lichvar <mlich...@redhat.com> > --- > port.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/port.c b/port.c > index 10bb9e1..fb420fb 100644 > --- a/port.c > +++ b/port.c > @@ -2744,7 +2744,10 @@ static enum fsm_event bc_event(struct port *p, int > fd_index) > } > if (msg_sots_valid(msg)) { > ts_add(&msg->hwts.ts, -p->rx_timestamp_offset); > - clock_check_ts(p->clock, tmv_to_nanoseconds(msg->hwts.ts)); > + if (p->state == PS_SLAVE) { > + clock_check_ts(p->clock, > + tmv_to_nanoseconds(msg->hwts.ts)); > + } > } > > switch (msg_type(msg)) { > -- > 2.26.3 _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
