> -----Original Message-----
> From: Richard Cochran <richardcoch...@gmail.com>
> Sent: Friday, November 27, 2020 6:05 AM
> To: Karthikkumar V <karthikh...@gmail.com>
> Cc: linuxptp-users@lists.sourceforge.net
> Subject: Re: [Linuxptp-users] Phase offset reported is too high
> intermittently on
> PTP4L
>
> 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.
>
Hmmmm... If there is a scheduling issue.. I was wondering if perhaps the bug
might be a missed wraparound on a cycle counter if things really did get
stalled for over half a second... but i40e driver doesn't use a cyclecounter,
so that's not it.
> > driver: i40e
> > version: 2.10.19.82
> > firmware-version: 7.20 0x800082b3 1.2585.0
>
Hmm. I'm relatively familiar with this driver. What kernel version are you
using? Are you using the in-kernel driver, or one built from the out-of-tree
sourceforge release?
> > b5:00.0 Ethernet controller: Intel Corporation Ethernet Controller XXV710
> > Intel(R) FPGA Programmable Acceleration Card N3000 for Networking (rev 02)
>
Am not aware much of this particular device. Perhaps it has done something
funky that doesn't work.
> 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.
>
I'd be curious to see this information as well.
> Thanks,
> Richard
>
>
> _______________________________________________
> Linuxptp-users mailing list
> Linuxptp-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linuxptp-users
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
