On Fri, Nov 15, 2019 at 11:54:58AM +0000, Mikael Arvids via Linuxptp-users wrote:
> 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. Looks like it. > It seems to us that this check will only work if ptp4l is always > scheduled at precise intervals, which is not the case here. Right. > 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? Yes, it could be. You have some choices: 1. Disable sanity_freq_limit check (if your sure your oscillators are good). 2. Characterize the scheduling latency of your system using cyclictest. If you do indeed have large (25+ millisecond) latency, then you can ignore the warning (choice 1) or 3. Give ptp4l priority using chrt. If you *still* have large latency, then 4. Use a preempt_rt kernel. HTH, Richard _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
