Hi NVIDIA Team,
I am currently evaluating the Jetson Thor platform and have a question regarding time synchronization.
I understand that NVIDIA platforms typically support hardware-stamped PTP via the MAC controllers. However, for my specific use case and testing, I would like to know if software-based PTP time synchronization (soft timestamping) is fully supported on the Thor architecture, specifically on the mgbe0_0 interface.
My Environment:
- Hardware Platform: Jetson Thor
- Software Version: 7.1
- Host OS: Ubuntu 24.04
- Network Interface:
mgbe0_0
My Questions:
- Does the
mgbe network driver and Linux kernel in this release fully support PTP software timestamping (e.g., running ptp4l -i mgbe0_0 -m -S)?
- Are there any known driver bugs, limitations, or specific configurations required in the device tree / kernel to enable reliable soft time synchronization on the
mgbe0_0 interface?
Thanks in advance for your support!
This doesn’t fully answer your question, but it is some information.
linuxptp works well with holoscan-sensor-bridge.
ethtool -T mgbe0_0
Time stamping parameters for mgbe0_0:
Capabilities:
hardware-transmit
software-transmit
hardware-receive
software-receive
software-system-clock
hardware-raw-clock
PTP Hardware Clock: 1
Hardware Transmit Timestamp Modes:
off
on
onestep-sync
Hardware Receive Filter Modes:
none
ptpv1-l4-sync
ptpv1-l4-delay-req
ptpv2-l4-sync
ptpv2-l4-delay-req
ptpv2-l2-sync
ptpv2-l2-delay-req
ptpv2-event
mgbe driver is supposed to be improved with Jetpack 7.2 once it is released.
Here is how I installed linuxptp on Thor.
# Following gets systemd services and /etc/linuxptp/ /usr/share/doc/linuxptp/configs/ config files.
sudo apt install linuxptp
# Then get current version
git clone http://git.code.sf.net/p/linuxptp/code linuxptp
cd linuxptp
make
sudo cp hwstamp_ctl nsm phc2sys phc_ctl pmc ptp4l timemaster ts2phc tz2alt /usr/sbin/
cat /etc/systemd/system/ptp4l-mgbe0_0.service
[Unit]
Description=Send PTP SYNC messages to mgbe0_0
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
ExecStartPre=/bin/sh -c 'for i in $(seq 1 30); do cat /sys/class/net/mgbe0_0/carrier | grep -q 1 && exit 0; sleep 1; done; exit 1'
ExecStartPre=/usr/sbin/hwstamp_ctl -i mgbe0_0 -t 1 -r 12
ExecStart=/usr/sbin/ptp4l -i mgbe0_0 -f /etc/linuxptp/ptp4l.conf -m -2 -l 6
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
--
cat /etc/systemd/system/phc2sys-mgbe0_0.service
[Unit]
Description=Sync PHC on mgbe0_0 from system clock
BindsTo=ptp4l-mgbe0_0.service
After=ptp4l-mgbe0_0.service
After=network-online.target time-sync.target
Wants=network-online.target time-sync.target
[Service]
Type=simple
ExecStart=/usr/sbin/phc2sys -s CLOCK_REALTIME -c mgbe0_0 -w -m -l 6
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
cat /etc/linuxptp/ptp4l.conf
[global]
twoStepFlag 1
network_transport L2
delay_mechanism E2E
time_stamping hardware
hwts_filter check
step_threshold 0.00002
first_step_threshold 0.00002
tx_timestamp_timeout 50
priority1 127
priority2 128
domainNumber 0
logAnnounceInterval -3
logSyncInterval -4
logMinDelayReqInterval -4
announceReceiptTimeout 3
verbose 1
use_syslog 1
logging_level 6
--
cat /etc/linuxptp/hsb-ptp.conf
[global]
time_stamping hardware
hwts_filter check
network_transport L2
delay_mechanism E2E
tx_timestamp_timeout 50
domainNumber 0
walker@tegra-ubuntu:~$ sudo ptp4l -i mgbe0_0 -m -S
ptp4l[203126.894]: port 1 (mgbe0_0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[203126.894]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[203126.894]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[203133.942]: port 1 (mgbe0_0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[203133.942]: selected local clock 4cbb47.fffe.dd0268 as best master
ptp4l[203133.942]: port 1 (mgbe0_0): assuming the grand master role
ptp4l[203134.953]: timed out while polling for tx timestamp
ptp4l[203134.953]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[203134.953]: port 1 (mgbe0_0): send sync failed
ptp4l[203134.953]: port 1 (mgbe0_0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[203150.953]: port 1 (mgbe0_0): FAULTY to LISTENING on INIT_COMPLETE
ptp4l[203158.806]: port 1 (mgbe0_0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[203158.806]: port 1 (mgbe0_0): assuming the grand master role
ptp4l[203159.816]: timed out while polling for tx timestamp
However, this software time synchronization command has this problem.
walker@tegra-ubuntu:~$ ptp4l
no interface specified
usage: ptp4l [options]
Delay Mechanism
-A Auto, starting with E2E
-E E2E, delay request-response (default)
-P P2P, peer delay mechanism
Network Transport
-2 IEEE 802.3
-4 UDP IPV4 (default)
-6 UDP IPV6
Time Stamping
-H HARDWARE (default)
-S SOFTWARE
-L LEGACY HW
Other Options
-f [file] read configuration from 'file'
-i [dev] interface device to use, for example 'eth0'
(may be specified multiple times)
-p [dev] Clock device to use, default auto
(ignored for SOFTWARE/LEGACY HW time stamping)
-s client only synchronization mode (overrides configuration file)
-l [num] set the logging level to 'num'
-m print messages to stdout
-q do not print messages to the syslog
-v prints the software version and exits
-h prints this message and exits
The software TX timestamp on raw AF_PACKET (L2) sockets appears to be broken on uname -r 6.8.12-tegra. The kernel never puts the software TX timestamp into the error queue for that socket type.
Hopefully Jetpack 7.2, when released, fixes this bug.
Only have hardware PTP time sync as I know.