PTP sync MAC address issues

Autonomous Vehicles DRIVE AGX Xavier DRIVE AGX Xavier General
1

We were having an issue with radars connected to 1Gb HSD ports not correctly setting time according to PTP messages. Either the radars never receive the messages from the PTP master (xavier A) or their “path delay requests” are being lost on the way from the sensor to the PTP master. The board is pre-loaded with the default PTP service and settings in “/home/nvidia/drive-t186ref-linux/samplse/nvavb/daemons/{gPTP.conf,gPTP_slave.conf}”. We inspected the PTP packets in Wireshark, and saw the correct SYNC/ANNOUNCE messages are being output by the PTP master.

Somewhere in the DriveOS docs it talks about how the switch is configured to pass through the 802.1 timing packets without modification, but on a guess I went into the gPTPconf/gPTP_slave.conf and both the “ptp_dst_mac” and “p2p_dst_mac” multicast ethernet addresses to another multicast address listed on this wikipedia page .

Then viola when 01:80:C2:00:00:03 is used (for both, and master and slave), everthing works. Master and slave Xaviers sync together, and our radars properly sync.

So in summary, what other downstream affects will there be if we change the PTP multicast address? I haven’t tested interaction with Aurix or cameras. In addition, the behavior doesn’t seem to be consistent across all our boards. Would like to rule out incorrect switch configuration if possible.

From the terminal on XA/XB, if one installs “tshark” you can view the PTP sync messages in the following manner:

sudo tshark -i eth0 -Y ‘ptp’

Hardware Platform: [Example: DRIVE AGX Xavier™ Developer Kit, DRIVE AGX Pegasus™ Developer Kit]
AGX Pegasus Devaloper Kit

Software Version: [Example: DRIVE Software 10, DRIVE Software 9]
Drive software 10

Host Machine Version: [Example: native Ubuntu 18.04]
NA

SDK Manager Version: [Example: 1.0.1.5538]

2

Dear @ChrisB,
Could you share the Radar details? Do you see any issue in running DW radar samples?

4

We have ARS430 RDI. We wrote a custom decoder plugin.

5

Dear @ChrisB,
the behavior doesn’t seem to be consistent across all our boards. Would like to rule out incorrect switch configuration if possible.

Does that mean you don’t notice this issue on other boards with same RADAR?

6

Well I guess what I was observing is my “fix” not really working. I tried so many configurations that it happened to work, possibly as a side affect of something I changed but did not record. After a reboot with the MAC’s changed in the PTP config file, the XavierB could not understand the PTP messages of XavierA.

Here’s what I have established:

  • radar will synchronize PTP as long as the ethernet MACs in the gPTP.conf are NOT “01:80:C2:00:00:0E”. So changing to “01:80:C2:00:00:00” works for syncing the radars.

  • xavier will synchronize as long as both MACs in master and slave configs are “01:80:C2:00:00:0E”

To remedy the situation so everything works on startup, I’m running two instances of “ptp4l” in the master service as follows:

/etc/systemd/scripts/tegra_ptp.sh, lines 121-122
 $PTP4L -f $PTP_MASTER_CFG -p /dev/$node -i eth0 -m -D > $PTP4L_SAVE_LOG 2>&1 < /dev/null &
 $PTP4L -f $PTP_MASTER_CFG2 -p /dev/$node -i eth0 -m -D > $PTP4L_SAVE_LOG 2>&1 < /dev/null &

Then the “PTP_MASTER_CFG2” is just a copy of configuration1 with both MACs changed to “01:80:C2:00:00:00” in the config.

I gather running two instances of PTP4l on the same interface is definitely not ideal. I’d like to separate out by interface if possible so the RADAR get one set of messages and the xavierA-xavierB get another configuration. Not sure if that is possible since it is all “eth0”.

On a related note, can you explain what this flag in your version of PTP4l means? It is set by default, and I haven’t removed it.
-D Set to run ptp on DrivePx1 with non-EAVB switch

7

Dear @ChrisB,
We checked internally on this issue. Note that, DRIVE SW 10 can’t support PTP-enabled end points. The MAC address you are using is not supported for PTP, only for Link Layer Discovery protocol.

01-80-C2-00-00-00 , 01-80-C2-00-00-03 or 01-80-C2-00-00-0E 0x88CC Link Layer Discovery Protocol
01-1B-19-00-00-00 or 01-80-C2-00-00-0E 0x88F7 Precision Time Protocol (PTP) version 2 over Ethernet (native layer-2)

As we can’t support this officially from our side, we can’t predict stability or other problems this may cause.

9

Could you elaborate on this?
What does not function with 10/5.1.6.1?

10

You should try to use the “-D Set to run ptp on DrivePx1 with non-EAVB switch” option on the Grand Master to enable the Master and Slave to work on this non-EAVB switch.