Re: [Linuxptp-users] received SYNC without timestamp

[Martin Pecka]

Thanks for the very prompt reply, Jake. My answers below.

What version of the kernel and drivers are you using?

Linux clone-robot-jetson 4.9.253-tegra #1 SMP PREEMPT Mon Jul 26 12:19:28 PDT 2021 aarch64 aarch64 aarch64 GNU/Linux

driver: igb
version: 5.4.0-k
firmware-version: 1.2.1

driver: ixgbe
version: 4.4.0-k

Unfortunately, it'd be difficult to test newer kernels as this is NVidia Jetson Xavier AGX, which needs an nvidia-customized kernel to run. They haven't issued yet any newer versions. But if there is a known bug in the NIC drivers in this kernel version, I'd understand that there's not much to do (except e.g. asking NVidia to backport the patches).

So this is the X540 which is receiving the frames? The "SYNC without
timestamp" means that the packet is received without a timestamp.

Yes, the problematic chips are X540 and 82576.

Could you check the ethtool stats output and see if rx_hwtstamp_cleared
is incrementing?

No, it is always zero on all tested cards. Even on the working card with I350.

Another possible check would be to use the test utility testptp and
verify that the network device clock is actually incrementing.

Ran the test, time is incrementing.

I believe "SYNC without timestamp" can occur if the reported timestamp is 0?

Is that the same as not set?

Could you try layer 3 UDP packets instead of L2?

No difference with either UDPv4 or UDPv6 transports. I also tried P2P instead of E2E, but still no difference.

Thanks for further help,
Martin

I attach two PCAPs from the client machine recorded using tshark. ptp_goog.pcapng is the case with I350 where PTP works. ptp_bad.pcapng is the case with 82576 where PTP does not work. I saw only one difference - logMessagePeriod is -3 in the bad case and 0 in the good case. But I couldn't find any documentation on what does this value mean. I'll add one maybe relevant information - the computer I use as a client has an integrated PTP-capable NIC, too (eqos driver). With this one, PTP sync works. And both the non-working PCIe cards are two-port cards (without an internal switch - each port is connected as a separated PCI device). So in the end, the system sees 3 NICs and 3 PTP clock devices. When running ptp4l, I always specify just the NIC and let ptp4l select the clock.

ptp_bad.pcapng
Description: application/pcapng

ptp_good.pcapng
Description: application/pcapng

smime.p7s
Description: Elektronicky podpis S/MIME

_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users