PTP4l software timesamp error on orin

Autonomous Machines Jetson & Embedded Systems Jetson AGX Orin
,
1

we use linuxptp to synchronization system time, when we use sofeware timesamt by option -S , will occur the error “increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug”

sudo ptp4l -S -4 -i eth0 -m 
[sudo] password for nvidia: 
ptp4l[1958.215]: port 1 (eth0): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1958.216]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1958.216]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE
ptp4l[1958.216]: Switched to /dev/ptp0 as PTP clock
ptp4l[1965.034]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1965.034]: selected local clock 48b02d.fffe.9550eb as best master
ptp4l[1965.034]: port 1 (eth0): assuming the grand master role
ptp4l[1966.045]: timed out while polling for tx timestamp
ptp4l[1966.045]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[1966.045]: port 1 (eth0): send sync failed
ptp4l[1966.045]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[1982.046]: port 1 (eth0): FAULTY to LISTENING on INIT_COMPLETE
ptp4l[1989.779]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[1989.780]: port 1 (eth0): assuming the grand master role
ptp4l[1990.790]: timed out while polling for tx timestamp
ptp4l[1990.790]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[1990.790]: port 1 (eth0): send sync failed
ptp4l[1990.790]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[2006.791]: port 1 (eth0): FAULTY to LISTENING on INIT_COMPLETE
ptp4l[2014.279]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[2014.279]: port 1 (eth0): assuming the grand master role
ptp4l[2015.289]: timed out while polling for tx timestamp
ptp4l[2015.289]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[2015.289]: port 1 (eth0): send sync failed
ptp4l[2015.289]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[2031.290]: port 1 (eth0): FAULTY to LISTENING on INIT_COMPLETE
ptp4l[2038.334]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[2038.334]: port 1 (eth0): assuming the grand master role
ptp4l[2039.344]: timed out while polling for tx timestamp
ptp4l[2039.344]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[2039.344]: port 1 (eth0): send sync failed
ptp4l[2039.344]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[2055.345]: port 1 (eth0): FAULTY to LISTENING on INIT_COMPLETE
ptp4l[2063.231]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[2063.232]: port 1 (eth0): assuming the grand master role
ptp4l[2064.242]: timed out while polling for tx timestamp
ptp4l[2064.242]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[2064.242]: port 1 (eth0): send sync failed
ptp4l[2064.242]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[2080.243]: port 1 (eth0): FAULTY to LISTENING on INIT_COMPLETE
ptp4l[2088.078]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[2088.078]: port 1 (eth0): assuming the grand master role
ptp4l[2089.088]: timed out while polling for tx timestamp
ptp4l[2089.088]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[2089.088]: port 1 (eth0): send sync failed
ptp4l[2089.088]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
ptp4l[2105.089]: port 1 (eth0): FAULTY to LISTENING on INIT_COMPLETE
ptp4l[2112.594]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES
ptp4l[2112.594]: port 1 (eth0): assuming the grand master role
ptp4l[2113.604]: timed out while polling for tx timestamp
ptp4l[2113.604]: increasing tx_timestamp_timeout may correct this issue, but it is likely caused by a driver bug
ptp4l[2113.604]: port 1 (eth0): send sync failed
ptp4l[2113.604]: port 1 (eth0): MASTER to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)

system env:
R35 (release), REVISION: 1.0, GCID: 31250864, BOARD: t186ref, EABI: aarch64, DATE: Thu Aug 11 03:40:29 UTC 2022

2

Moved to AGX Orin forum.

4

Sorry for the late response, is this still an issue to support? Thanks

5

yes

7

Any support here？

9

Hi
I meet the same issue. Does the NVDIA have any suggestions?
Thanks!

11

Hi,

Is this based on Orin to Orin port to port connection?

12

Test evn is Orin to Radar. Is no-relation with connect type. Orin to xavier, the problem still exists.

13

We tested on Orin to Orin connection but cannot reproduce your issue.

15

@WayneWWW
How do you test? Can you show your command?
I do the time sync with lidar over the eqos_0, it report the same error.
Thanks!

16

which SDK do you test? we test on l4t R35, and linuxptp v3.1 ; command line is "sudo ptp4l -S -4 -i eth0 -m ". Any problem with my operation?

17

Hi,

It is just

Master:
$ sudo ptp4l -i eth0 -m
Slave:
$ sudo ptp4l -i eth0 -m -s

18

And my ptp version:

./ptp4l -v
3.1-00235-gc411770

19

You need to add “-S” options, to special the “Softwart timestamp”. linuxptp default use hardware timestamp.

20

Ok, could you confirm is hardware timestamp is working on your side first?

22

The slave device is software timestamp, there is an 8-hour time difference between hardware timestamp. Even add offset value to fix it , there is a 50ms deviation here.

23

Can you repeat this issue? Can you provide a rough idea of what part of the code is the fault point of the problem?

24

Hi,

Could you use orin to orin connection and test the software timestamp first? We don’t have your device so unlikely to reproduce your issue.

25

You can test orin with Ubuntu PC or orin with xavier.

26

I know. But we don’t have device available for now. If it is urgent to you, then please test on your side first.