Nvidia Orin linuxptp (ptp4l) hardware timestamping[Uploading: ptp4l.conf...]()


I want to synchronize the clocks of a slave sensor and the Nvidia Jetson Orin as master via ptp4l using L2 and P2P. The sensor and the Orin are connected directly via ethernet. The setup works perfectly, if I replace the Orin by a Notebook running the same Ubuntu version 20.04. However, the Orin throws the following error “: ioctl SIOCSHWTSTAMP failed: Numerical result out of range”. I found some forums adressing similiar issues, but never a solution was given. Here the question: Does the Orin support ptp hardware timestamping and if yes, how to activate it?

Please find my configuration file attached as a reference only.

Thank you.

Best regards
ptp4l.conf (288 Bytes)

Is this what you want to do?

1 Like

Hi Wayne, thanks for your fast response. To be more precise: the following command executed on the Orin throws an Error:

Command: "sudo ptp4l -i eth0 -m -2
Error: “ioctl SIOCSHWTSTAMP failed: Numerical result out of range”

However, we need the option -2 (Layer2), as the sensor does only support ptp over Layer2 and not UDP. However, it seems that the Orin does not support ptp via Layer2? Can you please clarify if this is the case? Thank you.

Is there no one that has experience with L2 ptpt and Nvidia Orin?


as I did not receive an answer since a while, I try to further clarify our problem:

We are currently trying to use ptp4l on a NVIDIA Orin to sync with a couple of sensors using layer 2 ptp. However, we get the following error when starting the master instance on the Orin:

    uam@hubble:~$ sudo ptp4l -i eth0 -m -2 -l 7
    ptp4l[922.980]: selected /dev/ptp0 as PTP clock
    ptp4l[923.053]: driver rejected most general HWTSTAMP filter
    ptp4l[923.059]: ioctl SIOCSHWTSTAMP failed: Numerical result out of range
    ptp4l[923.120]: port 1 (eth0): INITIALIZING to FAULTY on FAULT_DETECTED (FT_UNSPECIFIED)
    ptp4l[923.121]: port 0 (/var/run/ptp4l): INITIALIZING to LISTENING on INIT_COMPLETE
    ptp4l[923.121]: port 0 (/var/run/ptp4lro): INITIALIZING to LISTENING on INIT_COMPLETE

Our current understanding is that the Orin should support ptp via L2, due to the following output of the ethtool:

uam@hubble:~$ ethtool -T eth0
    Time stamping parameters for eth0:
        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)

We are using these versions:
ptp4l: 3.1-00224-gd4adf87
kernel: 5.10.104-tegra

Are there any mistakes on our side? What else can we try?


we also sent the question to the linuxptp mailing list and got the response that this is likely a bug in the vendor kernel aka 5.10.104-tegra ( linuxptp thread).
It would be great if you could look into this. If we can provide any further information or help please let us know.

Thanks in advance,

1 Like

I found the error root cause about “: ioctl SIOCSHWTSTAMP failed: Numerical result out of range”.

linuxptp set rx_filter to HWTSTAMP_FILTER_PTP_V2_L2_EVENT, but nvidia orin driver not support

1 Like


I have changed

sudo ptp4l -i eth0 -m -f configs/automotive-master.cfg

it’s run

but for solve tx_timeout, i add tx_timestamp_timeout 1000 to configs/automotive-master.cfg

1 Like

Hi jindongshen1024,

We applied your proposed change and this seems to be the solution to our problem.
Thank you very much!

Best regards

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