Thanks Richard.
I guess the device you are referring, is the nic card.
Can you please suggest few things which we can try from linuxptp code to
isolate the problem further.
Regards,Ramesh .
On Friday, December 11, 2020, 07:17:14 PM GMT+5:30, Richard Cochran
<[email protected]> wrote:
Your mailer is doing weird stuff, but I reformatted the message to
make it legible ...
On Fri, Dec 11, 2020 at 10:55:04AM +0000, ramesh t via Linuxptp-users wrote:
> Have connected two servers (Intel NIC: XXV710) with 10Gige
> interface. One server is running PTP master instance and another
> server is running PTP slave instance. With no data traffic the rms
> and path delay seems to be stable.
> ptp4l[6406.152]: rms 4 max 9 freq +6569 +/- 6 delay 508 +/- 2
> ptp4l[6407.152]: rms 3 max 5 freq +6563 +/- 3 delay 506 +/- 1
okay ...
> On start of data traffic between two servers using iperf, observing
> changes in rms value and path delay. This observation is seen with
> L2 and UDPv4 PTP (*dscp 0 and 56) packets
> ptp4l[6408.152]: rms 67 max 128 freq +6627 +/- 106 delay 508 +/- 1
> ptp4l[6409.154]: rms 72 max 133 freq +6544 +/- 112 delay 517 +/- 23
> ptp4l[6410.154]: rms 90 max 144 freq +6562 +/- 150 delay 527 +/- 23
> ptp4l[6411.154]: rms 63 max 104 freq +6538 +/- 104 delay 508 +/- 8
> ptp4l[6412.155]: rms 67 max 132 freq +6553 +/- 111 delay 515 +/- 14
> ptp4l[6413.155]: rms 84 max 140 freq +6581 +/- 137 delay 527 +/- 28
> ptp4l[6414.155]: rms 69 max 128 freq +6616 +/- 110 delay 507 +/- 1
I see, you have a larger max, larger rms, and more variable delay.
Interesting.
> Can you please help here? 1) Is this NIC driver issue?
I doubt that. The time stamps are generated in HW, not in the driver.
This is a problem in the device itself.
Sorry,
Richard
_______________________________________________
Linuxptp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
