we are trying to set up a Orin-AGX Dev-Kit of yours to act as a PTP-Grandmaster.
For our goal to achieve best performance we attached a PPS to the carrierboard own AQR113C sync pin, available via test point TP2702 indicated by the schematics.
Running ethtool -T we get - like many others have reported here - the output “PTP Hardware Clock: 0”.
We set chrony up for PHC via /dev/ptp0, but the time increment seems not to be driven by the PPS, as we can disconnect the PPS with no effect, and still polling an increment, but freq = 0.
We have read quite an substantial amount of posts, starting from PPS in via GPIO up to updating the AQR113 firmware, which seems to be no straight forward approach.
We hope the support or an interested reader might be able to give us a hint.
Can the ARQ113 be configured to accept the PPS, so we can use the fractional secs to control the system clock ?
From AQR113 manual:
Sync_1588:
This is the PTP sync input used to align the PTP clocks on multiple PHYs on a platform to have the same time. The PHY timestamps the rising edge of this input and this timestamp can then be used on each of the PHYs to perform the alignment.
ethtool:
the latest version of ethtool available via apt is 5.16, that is what is on our Dev-Kits (5 of them in total).
This version seems to have a display bug - see No timestamp capabilities with ethtool -T.
Hence, this is the output of two of our Dev-Kits i have access to:
But i assume the timestamping capabilities should be identical to all Dev-Kits ?
ptp4l:
As of now, we are trying to use the PPS input of the NIC as a high precision, low delay hw timestamping unit, using chrony with it’s refclock command with the phc option, as stated in the chrony docs.
(see chrony doc - see “refclock” segment):
“Alternatively, the pps refclock option can be enabled to treat the PHC as a PPS refclock, using only the sub-second offset for synchronisation. The driver supports the following options: ….”
As /dev/ptp0 is available (access is granted), we have tried the following chrony command : refclock PHC /dev/ptp0:extpps,pin=0
but it does not like the “extpps” option. We are stuck here.
So, as our first goal, we want to have a chrony disciplined systemclock using the phc “Sync_1588” pin for precise timing.
We are aware of the fact, that ethtool gives us PTP Hardware Clock: 0.
/dev/ptp0 is available - as with all our Dev-Kits
/dev/ptp1 is not - as with all our Dev-Kits
Edit:
Using
cat /sys/class/ptp/ptp0/clock_name
we obtain
ether_ptp_clk
So, by now we assume that the available /ptp0 is established via the nvethernet driver and the AQR113 ist not a separate PCI-Device but rather used as a PHY connected to the Jetson internal MGBE controller. Hence there is no ARQ113-PHC available. Otherweise there would be a /ptp1.
We have tried using the pps-gpio approach, and tuned the approach by clearing a CPU for pure PPS tasks, setting CPU governor and raising task priorities, but timestamping is showing errors in the range of 300 to 2000µs, which is not sufficient for multisensor applications we are having.
Hence we were looking for the alternative route via PHC.
Please let me know, if you have further input on how to improve the accuracy of the PPS-GPIO approach.
phc2sys:
From what i understand, this would be the 2nd stage in our attempt.
For the 2nd stage to make sense, we need to establish a PTP-Grandmaster on the Jetson (standalone setup with sensors) using the GNSS-PPS to sync systemtime. If successful with a synched systemtime - hopefully stable - we would want to control the PHC to send PTP messages to clients.
But at this point - stage 1 - we seem not able to establish a synched systemtime with suffiicient accuracy.
Please correct, if i am wrong.
P.S.
I am unavailable for the end of this and the following week.
Yes, you are correct.
The quality of a PTP Grandmaster is entirely dependent on the quality of its reference time source.That reference source is the system clock in current case. If the system clock itself is not sufficiently accurate, all subsequent operations, including syncing the PHC with phc2sys will fail to meet your precision requirements.
Please check if using RT kernel may help for this case.
