“PTP synchronization issue: sensors receiving wrong time due to dual PTP sources on mgbe2_0”

Autonomous Vehicles DRIVE AGX Orin DRIVE AGX Orin General
1

Software Version
DRIVE OS 6.0.10.0
DRIVE OS 6.0.8.1
DRIVE OS 6.0.6
DRIVE OS 6.0.5
DRIVE OS 6.0.4 (rev. 1)
DRIVE OS 6.0.4 SDK
other

Target Operating System
Linux
QNX
other

Hardware Platform
DRIVE AGX Orin Developer Kit (940-63710-0010-300)
DRIVE AGX Orin Developer Kit (940-63710-0010-200)
DRIVE AGX Orin Developer Kit (940-63710-0010-100)
DRIVE AGX Orin Developer Kit (940-63710-0010-D00)
DRIVE AGX Orin Developer Kit (940-63710-0010-C00)
DRIVE AGX Orin Developer Kit (not sure its number)
other

SDK Manager Version
2.1.0
other

Host Machine Version
native Ubuntu Linux 20.04 Host installed with SDK Manager
native Ubuntu Linux 20.04 Host installed with DRIVE OS Docker Containers
native Ubuntu Linux 18.04 Host installed with DRIVE OS Docker Containers
other

Issue Description
We are setting up PTP synchronization on DRIVE AGX Orin with multiple radars connected.

Time source / pipeline

  • Ground-truth time comes from an GNSS GrandMaster (PTP GM) connected on mgbe0_0 (ptp0).

  • ptp4l runs in Boundary Clock mode (hardware timestamping, JBOD), detects the GM and distributes PTP on the sensor ports.

  • We synchronize clocks as follows:

    1. GM PHC → CLOCK_REALTIME (via phc2sys-gm.service)

    2. CLOCK_REALTIME → each PHC on the sensor ports (via multiple phc2sys-to@ptpX.service, one per /dev/ptpX)

Configurations used (attached):

  • ptp4l-bc.conf (Boundary Clock mode, JBOD enabled, hardware timestamping).

  • ptp4l-bc.service for launching ptp4l.

  • Multiple phc2sys-to@ptpX.service files.

Problem:
All 5 radars successfully receive PTP messages, but they do not synchronize to the correct UTC time.
On interface mgbe2_0, we observe two different PTP clocks being advertised simultaneously:

  1. From the GNSS GrandMaster GM (expected, UDP transport).

  2. Another apparently generated by the internal switch behind mgbe2_0 (L2 transport). This second time source corresponds to the time since the AGX boot, not UTC.

Screenshot: Wireshark capture on mgbe2_0 with a PTP filter, showing both sets of messages.

image
image1022×378 32.5 KB

This dual advertisement causes inconsistent time distribution and incorrect timestamps at radar level.

Request for guidance

  • How can we disable or synchronize the internal PTP clock from the switch behind mgbe2_0?

  • Are there best practices for using Boundary Clock + multiple phc2sys instances in DRIVE OS to ensure consistent UTC distribution to all sensors?

Attachments

ptp4l-bc.conf.txt (514 Bytes)

ptp4l-bc.service.txt (209 Bytes)

phc2sys-gm.service.txt (373 Bytes)

phc2sys-to@ptp1.service.txt (398 Bytes) (example – services exist for ptp1 to ptp5, all identical except for the ptpX index)

4

Dear @jean-baptiste.braconnier ,
So your objective is to sync radar timestamps to external GM ?

5

Yes, the goal is for the radars to take their timestamps from the PTP stream provided by 192.168.100.30, which is properly synchronized with CLOCK_REALTIME. CLOCK_REALTIME itself is disciplined by the Grandmaster clock received on mgbe0_0 from a GNSS system.

However, there is an additional unsynchronized PTP signal not aligned with CLOCK_REALTIME that interferes with the radars’ operation.

7

Dear @jean-baptiste.braconnier ,
So GM is connected at mgb0_0 interface and you want to sync radar timestamps to GM. Are you using DW to get radar timestamp data? If so, can you check if setting DW_PPS_INTERFACE env variable to mbge0_0 and check if radar timestamps ?

8

We are not using DriveWorks (DW). We are only using PTP messages over Ethernet provided by the AGX Xavier using ptp4l. As previously presented, our ptp4l setup seems to work well. However, there is another PTP signal provided directly on the mgbe2_0 interface which, as I understand, is coming from the switch.

9

Dear @jean-baptiste.braconnier ,
Oak switch is configured to use ptp l2 for AVNU profile, so all radar connected to sensor port (P1~P6) will receive PTPv2 broadcast packet.
Could you check if setting setnetworkconfig to
NW_CFG_BASE_SAFETY helps.

Please see https://developer.nvidia.com/docs/drive/drive-os/6.0.10/public/drive-os-linux-sdk/common/topics/network_stub/network_configuration.html for details.

10

Hi,

After switching to NW_CFG_BASE_SAFETY, PTP is now correctly generated only by the AGX and no longer by the OAK switch. Synchronization works as expected, and the radars are receiving the PTP signal from the AGX via mgbe0_0.

However, I am now facing a new issue: on port 1 (mgbe2_0), PTP keeps transitioning to the FAULTY state. Here are the relevant logs:

ptp4l[1800.789]: port 1 (mgbe2_0): master sync timeout  
ptp4l[1800.799]: port 1 (mgbe2_0): rogue peer delay response  
ptp4l[1800.799]: port 1 (mgbe2_0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)  
ptp4l[1800.908]: waiting 2^4 seconds to clear fault on port 1 (mgbe2_0)  
ptp4l[1816.908]: clearing fault on port 1 (mgbe2_0)

I have attached longer logs here:

issue3.txt (20.5 KB)

It looks like a rogue peer is still being detected on mgbe2_0, which causes sync timeouts and repeated fault transitions. This impacts the stability of time distribution to the radars.

For troubleshooting, I have removed mgbe2_0 from the Boundary Clock configuration, and I am now running ptp4l directly on mgbe2_0 using the automotive_master configuration.

Do you have any recommendations on how to identify or eliminate this rogue peer? Could it be due to a leftover configuration from the switch, or something else in the network?

Thanks a lot for your support!

11

Dear @jean-baptiste.braconnier ,
Let me check internally if any work around can be provided for this.
Could you reach out to marvell as well for customizing your use case?

12

Could you please provide any update for this topic?

13

Could you please provide any update for this topic?

14

Could you please provide any update for this topic?

15

Please reach out to marvell for customizing your use case.

16

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.