Hi, We are using linuxptp v1.8 in a data acquisition system that handles quite a lot of data and therefore has constant high cpu load. We have seen problems with the clock sanity check that we think is related to the high load of the system.
We have added traces of the intervals to each clockcheck and we see that sometimes the interval of the monotonic clock is way larger than expected (25 ms longer, as we can see at 77381.239 in the trace), which we believe is caused by the ptp4l process is not allowed to run for some time. It seems to us that this check will only work if ptp4l is always scheduled at precise intervals, which is not the case here. ptp4l[77380.959]: clockcheck: interval=126192730 mono_interval=126242010 ptp4l[77380.971]: clockcheck_set_freq: 60511 ptp4l[77381.088]: clockcheck: interval=129188507 mono_interval=129253580 ptp4l[77381.089]: clockcheck_set_freq: 60488 ptp4l[77381.239]: clockcheck: interval=127914173 mono_interval=151503620 ptp4l[77381.240]: clockcheck_set_freq: 60483 ptp4l[77381.342]: clockcheck: clock jumped forward or running faster than expected! ptp4l[77381.342]: clockcheck: interval=125864275 mono_interval=102352040 ptp4l[77381.342]: clockcheck: max_foffset=229644888.479635 min_foffset=229644882.331783 freq_limit=200000000 ptp4l[77381.343]: port 1: SLAVE to UNCALIBRATED on SYNCHRONIZATION_FAULT ptp4l[77381.474]: clockcheck: interval=126654838 mono_interval=131442870 ptp4l[77381.475]: rms 112 max 156 freq -60491 +/- 11 delay 554 +/- 0 ptp4l[77381.599]: clockcheck: interval=127212116 mono_interval=125727460 ptp4l[77381.599]: clockcheck_set_freq: 60325 ptp4l[77381.599]: port 1: UNCALIBRATED to SLAVE on MASTER_CLOCK_SELECTED ptp4l[77381.721]: clockcheck: interval=125912143 mono_interval=122308450 ptp4l[77381.722]: clockcheck_set_freq: 60334 ptp4l[77381.848]: clockcheck: interval=126815529 mono_interval=126867090 ptp4l[77381.849]: clockcheck_set_freq: 60310 ptp4l[77381.975]: clockcheck: interval=127584585 mono_interval=127490440 We have disabled the clock sanity for now by setting sanity_freq_limit to 0 since we believe that this is a false positive, but could it be that we are hiding an actual fault by doing this? Best regards, Mikael Arvids *************************************************************** Consider the environment before printing this message. To read the Company's Information and Confidentiality Notice, follow this link: http://www.veoneer.com/en/important-information-and-confidentiality-notice ***************************************************************
_______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
