On Fri, Nov 27, 2020 at 04:51:26PM +0530, Karthikkumar V wrote: > ptp4l[1356003.918]: rms 39 max 57 freq -931 +/- 23 delay 539 +/- 0 > ptp4l[1356005.065]: rms 12 max 18 freq -894 +/- 12 delay 539 +/- 0 > ptp4l[1356006.637]: rms 123133375 max 376355930 freq -77833623 +/- 186202293 > delay 539 +/- 1 > ptp4l[1356007.644]: rms 14738423 max 31049776 freq -33465212 +/- 15404633 > delay -1568 +/- 7861
The program appears to have been blocked for about 1/2 second. > I tried bumping up the priority of the service using the following commands > in the service file, but still we are seeing the issues. > > CPUSchedulingPolicy=fifo > CPUSchedulingPriority=45 Okay, so that very likely rules out having been preempted for 1/2 second. Even if ptp4l were preempted for so long, still that should not affect the offset, since the calculation uses HW time stamps. > driver: i40e > version: 2.10.19.82 > firmware-version: 7.20 0x800082b3 1.2585.0 > b5:00.0 Ethernet controller: Intel Corporation Ethernet Controller XXV710 > Intel(R) FPGA Programmable Acceleration Card N3000 for Networking (rev 02) I don't have that much experience with this driver. The problem sounds like a driver/HW issue. I would next trace the time that ptp4l spends in system calls. You can do this with 'strace -T' or kernel ftrace events. You might find that ptp4l spends lots of time in recv() or clock_adjtime(), for example. That would confirm that the root cause of the issue is in the driver or HW. Thanks, Richard _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
