PTP对时启动出现问题

After starting PTP master clock synchronization, the log error occurred when ptp4l GrandMaster was started
ptp4l[67736.277]: port 1: announce timeout
ptp4l[67736.278]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[67736.278]: selected local clock 3c6d66.fffe.33eb0e as best master
ptp4l[67736.278]: assuming the grand master role
ptp4l[67736.279]: port 1: master tx announce timeout
ptp4l[67737.278]: port 1: master sync timeout
ptp4l[67737.779]: timed out while polling for tx timestamp
ptp4l[67737.779]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[67737.779]: port 1: send sync failed
ptp4l[67737.779]: port 1: MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[67737.779]: waiting 2^{4} seconds to clear fault on port 1
Is there a problem with this kernel driver? What is the solution?

ptp4l config

Run time options

assume_two_step 0
logging_level 7
path_trace_enabled 0
follow_up_info 0
hybrid_e2e 0
net_sync_monitor 0
tx_timestamp_timeout 500
use_syslog 1
verbose 0
summary_interval 0
kernel_leap 1
check_fup_sync 0

Default interface options

network_transport UDPV4
delay_mechanism E2E
time_stamping hardware
tsproc_mode filter
delay_filter moving_median
delay_filter_length 10
egressLatency 0
ingressLatency 0
boundary_clock_jbod 0

*** Please note that this reply is generated by LLM automatically ***

The log error you’re experiencing with ptp4l suggests a problem with the kernel driver, specifically with the timestamping functionality. The error messages indicate a series of timeouts and failures in the synchronization process, ultimately leading to a fault detection on the port.

The ptp4l daemon is a user-space implementation of the Precision Time Protocol (PTP), which relies on the kernel driver to provide timestamping functionality. The kernel driver in question is likely the mttcan kernel driver, which is responsible for handling the CAN (Controller Area Network) interface.

The error messages suggest that the kernel driver is not providing the necessary timestamping information to ptp4l, leading to timeouts and failures in the synchronization process. This could be due to a bug in the kernel driver or a configuration issue.

To troubleshoot this issue, you can try the following:

  1. Check the kernel driver version: Ensure that you are running the latest version of the mttcan kernel driver. You can check the version by running the command modinfo mttcan.
  2. Verify CAN interface configuration: Make sure that the CAN interface is properly configured and enabled. You can check the configuration by running the command ip link show.
  3. Check PLL_C clock configuration: As mentioned in the context, the PLL_C clock is used as the parent clock for CAN on T194 platforms. Ensure that the PLL_C clock is properly configured and enabled.
  4. Enable PLLAON clock: If you need a higher clock frequency or greater accuracy, consider enabling the PLLAON clock and making it the parent clock of MTTCAN.
  5. Increase tx_timestamp_timeout: As suggested by the error message, increasing the tx_timestamp_timeout value may correct the issue. However, this is likely a workaround rather than a solution to the underlying problem.

To resolve the issue, you may need to update the kernel driver or modify the configuration of the CAN interface or PLL_C clock. If you are using a custom kernel driver, you may need to debug and fix the issue in the driver code.

In comparison to other platforms, the Jetson Xavier NX and Jetson AGX Xavier series devices are known to have specific requirements for CAN interface configuration and clock settings. Therefore, it’s essential to consult the NVIDIA documentation and ensure that your configuration meets the requirements for these platforms.

In summary, the problem is likely related to the kernel driver or configuration, and resolving the issue will require troubleshooting and potentially updating the kernel driver or modifying the configuration of the CAN interface or PLL_C clock.

Hi zhaozhijie1125,

Are you using the devkit or custom board for AGX Orin?
What’s the Jetpack version in use?

Please share the result of the following command on your board.

$ ethtool -T eth0

and also provide /etc/linuxptp/ptp4l.conf for further check.

cat /proc/device-tree/model:
Jetson AGX Orin Developer Kitysc

head /etc/nv_tegra_release:
R35 (release), REVISION: 4.1, GCID: 33958178, BOARD: t186ref, EABI: aarch64, DATE: Tue Aug 1 19:57:35 UTC 2023

ethtool -T eth0:
Time stamping parameters for eth0:
Capabilities:
hardware-transmit (SOF_TIMESTAMPING_TX_HARDWARE)
software-transmit (SOF_TIMESTAMPING_TX_SOFTWARE)
hardware-receive (SOF_TIMESTAMPING_RX_HARDWARE)
software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
hardware-raw-clock (SOF_TIMESTAMPING_RAW_HARDWARE)
PTP Hardware Clock: 0
Hardware Transmit Timestamp Modes:
off (HWTSTAMP_TX_OFF)
on (HWTSTAMP_TX_ON)
one-step-sync (HWTSTAMP_TX_ONESTEP_SYNC)
Hardware Receive Filter Modes:
none (HWTSTAMP_FILTER_NONE)
ptpv1-l4-sync (HWTSTAMP_FILTER_PTP_V1_L4_SYNC)
ptpv1-l4-delay-req (HWTSTAMP_FILTER_PTP_V1_L4_DELAY_REQ)
ptpv2-l4-sync (HWTSTAMP_FILTER_PTP_V2_L4_SYNC)
ptpv2-l4-delay-req (HWTSTAMP_FILTER_PTP_V2_L4_DELAY_REQ)
ptpv2-l2-sync (HWTSTAMP_FILTER_PTP_V2_L2_SYNC)
ptpv2-l2-delay-req (HWTSTAMP_FILTER_PTP_V2_L2_DELAY_REQ)
ptpv2-event (HWTSTAMP_FILTER_PTP_V2_EVENT)

/etc/linuxptp/ptp4l.conf:

[global]

Default Data Set

twoStepFlag 1
slaveOnly 0
priority1 127
priority2 128
domainNumber 0
#utc_offset 37
clockClass 6
clockAccuracy 0xFE
offsetScaledLogVariance 0xFFFF
free_running 0
freq_est_interval 1
dscp_event 0
dscp_general 0

Port Data Set

logAnnounceInterval 1
logSyncInterval 0
logMinDelayReqInterval 0
logMinPdelayReqInterval 0
announceReceiptTimeout 7
syncReceiptTimeout 3
delayAsymmetry 0
fault_reset_interval 4
neighborPropDelayThresh 20000000

Run time options

assume_two_step 0
logging_level 7
path_trace_enabled 0
follow_up_info 0
hybrid_e2e 0
net_sync_monitor 0
tx_timestamp_timeout 500
use_syslog 1
verbose 0
summary_interval 0
kernel_leap 1
check_fup_sync 0

Servo Options

pi_proportional_const 0.0
pi_integral_const 0.0
pi_proportional_scale 0.0
pi_proportional_exponent -0.3
pi_proportional_norm_max 0.7
pi_integral_scale 0.0
pi_integral_exponent 0.4
pi_integral_norm_max 0.3
step_threshold 0.0
first_step_threshold 0.00002
max_frequency 900000000
clock_servo pi
sanity_freq_limit 200000000
ntpshm_segment 0

Transport options

transportSpecific 0x0
ptp_dst_mac 01:1B:19:00:00:00
p2p_dst_mac 01:80:C2:00:00:0E
udp_ttl 1
udp6_scope 0x0E
uds_address /var/run/ptp4l

Default interface options

network_transport UDPV4
delay_mechanism E2E
time_stamping hardware
tsproc_mode filter
delay_filter moving_median
delay_filter_length 10
egressLatency 0
ingressLatency 0
boundary_clock_jbod 0

Clock description

productDescription ;;
revisionData ;;
manufacturerIdentity 00:00:00
userDescription ;
timeSource 0xA0

this may be helpful.

or in terminal

  1. start grand master role

sudo ptp4l -f /etc/linuxptp/ptp4l.conf -i eno1 -m -2

  1. run phc2sys

sudo phc2sys -s CLOCK_REALTIME -c eno1 -O 0 -m -S 0.001 -f /etc/linuxptp/phc2sys.conf

Hi zhaozhijie1125,

Could you configure it as 0 instead?

twoStepFlag 0

And remove above 2 lines to check if it could help for the original timeout issue.

“After making the configuration changes and starting the time synchronization, the log reported an error.
The master clock can be started on the Orin AGX, with the output log:”

ptp4l[14708.138]: port 1: received link status notification
ptp4l[14708.138]: interface index 3 is up
ptp4l[14708.909]: port 1: setting asCapable
ptp4l[14722.983]: port 1: announce timeout
ptp4l[14722.983]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[14722.983]: selected local clock 3c6d66.fffe.33eb0e as best master
ptp4l[14722.983]: assuming the grand master role

“The slave clock can normally receive synchronization information from the master clock, and it can display the clock offset with the master clock. Complete PTP (Precision Time Protocol) synchronization data packets, including sync, follow_up, delay_req, and delay_resp, can be captured on the host that initiates the master clock.
However, while the master clock successfully provides synchronization services, it continuously logs timeout messages. During this period, the slave clock continues to receive synchronization messages from the master clock and adjusts its own time accordingly.”

ptp4l[14722.983]: port 1: LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[14722.983]: selected local clock 3c6d66.fffe.33eb0e as best master
ptp4l[14722.983]: assuming the grand master role
ptp4l[14722.984]: port 1: master tx announce timeout
ptp4l[14723.983]: port 1: master sync timeout
ptp4l[14724.983]: port 1: master sync timeout
ptp4l[14724.984]: port 1: master tx announce timeout
ptp4l[14725.983]: port 1: master sync timeout
ptp4l[14726.984]: port 1: master sync timeout
ptp4l[14726.984]: port 1: master tx announce timeout
ptp4l[14727.984]: port 1: master sync timeout
ptp4l[14728.984]: port 1: master sync timeout
ptp4l[14730.985]: port 1: master tx announce timeout
ptp4l[14731.985]: port 1: master sync timeout
ptp4l[14732.985]: port 1: master sync timeout
ptp4l[14732.986]: port 1: master tx announce timeout
ptp4l[14733.985]: port 1: master sync timeout
ptp4l[14742.987]: port 1: master tx announce timeout
ptp4l[14742.987]: port 1: master sync timeout
ptp4l[14743.987]: port 1: master sync timeout
ptp4l[14744.987]: port 1: master tx announce timeout
ptp4l[14744.988]: port 1: master sync timeout
ptp4l[14745.988]: port 1: master sync timeout

And during the ongoing PTP synchronization, there is a certain probability that the network card driver may briefly disconnect and then reconnect (the master clock and the slave clock are directly connected via an Ethernet cable, which ensures the stability of the physical connection).

ptp4l[14751.989]: port 1: master sync timeout
ptp4l[14752.988]: port 1: master tx announce timeout
ptp4l[14752.989]: port 1: master sync timeout
ptp4l[14753.314]: port 1: received link status notification
ptp4l[14753.314]: interface index 3 is up
ptp4l[14753.989]: port 1: master sync timeout
ptp4l[14754.988]: port 1: master tx announce timeout
ptp4l[14754.989]: port 1: master sync timeout
ptp4l[14755.990]: port 1: master sync timeout
ptp4l[14756.989]: port 1: master tx announce timeout

It seems this error is missing in the current result.

About this error, have you tried to disable the firewall to check if it could help?

$ sudo ufw disable

Could you also try connecting the AGX Orin to another Linux host PC(act as slave) through ethernet to check if it could sync as expected?

Have you also tried using the latest JP5.1.5(r35.6.2) or JP6.2.1(r36.4.4) to verify?