the time used by the sensors connected to Switch-2
is synchronized to the MGBE-3’s PHC-Time.
The sensors are “Locked”, so they see a GM. But it is the time of the Switch-2 itselft, not the time we want to use.
One possible explanation could be that the relevant Switch-2 port, P10 / XFI-10G, cannot operate as a PTP client port. Since the direct switch-to-switch link P7 → P1 is internal and not configurable from Linux, we cannot analyze that connection. From the architecture diagram, we had assumed that a time source connected to Switch-1 could be forwarded through the internal Switch-1 ↔ Switch-2 link and then distributed to sensors on Switch-2 (see Why different PHC times between MGBE-2 and MGB-3 (Time synchro between switches)?), but it isn’t. At least not by default.
Could you please clarify:
Is the time propagation from Switch-1 P4 to sensors on Switch-2 supported at all?
If yes, does it require any specific switch firmware configuration, setting, or network configuration?
The sensors connected to Switch-2 only see the time of Switch-2’s GM, which appears to be completely isolated and not synchronized with the external GM connected to Switch-1. The GM identity used by the sensors is different, and the time itself also differs from the time on Switch-1.
How is this supposed to work? What is the intended path for the external GM time to be forwarded to the sensors on Switch-2?
Dear @Jis ,
Do you notice time sync happens in switch -1? Did you run any commands or settings apart from just connection. Also, share the ports where sensors connected. I will check with engineering team accordingly.
@SivaRamaKrishnaNV No, I did not. The only thing connected to Switch-1 is a sensor which can’t be a GM. There was no GM connected to any of the ports of the Orin.
ptp4l[263.972]: selected /dev/ptp2 as PTP clock
ptp4l[263.973]: port 1 (mgbe2_0): INITIALIZING to SLAVE on INIT_COMPLETE
ptp4l[263.973]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[265.972]: rms 60681004532311 max 1213620091047390 freq -10904 +/- 4123 delay 358 +/- 0
ptp4l[267.930]: rms 7876 max 17270 freq -18530 +/- 10183 delay 359 +/- 0
ptp4l[269.932]: rms 6768 max 11362 freq -28565 +/- 3346 delay 358 +/- 0
ptp4l[271.936]: rms 14786 max 30094 freq -4325 +/- 15975 delay 358 +/- 0
To inspect the time of all available PTP hardware clocks, I ran:
for phc in /dev/ptp*; do
echo "$phc"
sudo ./phc_ctl "$phc" get
done
Output:
/dev/ptp0
phc_ctl[1285.353]: clock time is 1283.824939596 or Thu Jan 1 00:21:23 1970
/dev/ptp1
phc_ctl[1285.363]: clock time is 1786435679.876352288 or Tue Aug 11 08:07:59 2026
/dev/ptp2
phc_ctl[1285.373]: clock time is 1787649300.000625258 or Tue Aug 25 09:15:00 2026
/dev/ptp3
phc_ctl[1285.382]: clock time is 1271.444883452 or Thu Jan 1 00:21:11 1970
/dev/ptp4
phc_ctl[1285.392]: clock time is 1787649300.019303396 or Tue Aug 25 09:15:00 2026
/dev/ptp5
phc_ctl[1285.401]: clock time is 1271.220099220 or Thu Jan 1 00:21:11 1970
Thus, /dev/ptp2 and /dev/ptp4 show the current time, while /dev/ptp0, /dev/ptp3, and /dev/ptp5 remain close to the Unix epoch. /dev/ptp1 shows an outdated date.
Since /dev/ptp3 belongs to mgbe3_0, it it shown, that the PHCs of mgbe2_0 and mgbe3_0 (which are the ports to which the switches connected to) are not synchronzed. Can you help me here?