DRIVE OS Version: 7.0.3
Issue Description: We’ve noticed large fluctuations in the offset when syncing network interface to system clock via phc2sys service.
Our setup:
Time server ↔ eqos_0
phc2sys service to sycn eqos_0 to CLOCK_REALTIME
The problem we observed:
When running the following command:
journalctl -fu phc2sys_eqos_to_sys.service
The offset observed from phc2sys seems to overshoot by 0.4ms (400us) followed by undershooting before returning to values close to 0. This happens regularly at random intervals.
Plot of the offset from a snippet of the above logs is below:
※phc2sys_eqos_to_sys.service is just a service that calls
phc2sys -s eqos_0 -c CLOCK_REALTIME -O 0 -S 1.0
Other Nv forum posts on a similar issue:
From searching the Nv forums we have found similar issues that have been posted, albeit on a different platform.
Jetson AGX Orin PHC Instability Using phc2sys - Jetson Systems / Jetson AGX Orin - NVIDIA Developer…
JP6.2系统时间跳变问题 - Jetson Systems / Jetson AGX Orin - NVIDIA Developer Forums
The solution from these posts seem to suggest turning off nvpps. However, that is not an option for us, we need nvpps to be enabled.
Question:
Does Nvidia see this as an issue and do you all intend to address it?
(Just asking to disable nvpps and closing the forum post does not seem like a resolution)
Dear @kunhao.toh.j5z ,
Could you test using DOS 7.2.5 release if there is no dependency on DOS 7.0.3?
So ethernet is connected to eqos interface and trying to sync system clock to eqos clock using phc2sys causing offset to go beyond 0.4 msec and comes back to normal. Is my understanding correct?
Can this be reproduced using phc2sys -s eqos_0 -c CLOCK_REALTIME -O 0 -S 1.0 on with ethernet connected to eqos interface?
What version linuxptp binaries are you using? linuxptp repo had update about 5 months ago to address:
The previous behaviour resulted in peer delays not being correctly
reported, which could break 802.1AS implementations that gate
asCapable on neighborPropDelayThresh, as well as reporting incorrect
accumulatedLatency values to 802.1Qat implementations that retrieve
the path delay from the management interface.
apt search linuxptp
linuxptp/noble-updates,now 4.0-1ubuntu1.1 arm64 [installed]
git clone https://github.com/richardcochran/linuxptp.git
cd linuxptp
make
mkdir bin
find . -path ./bin -prune -o -type f -executable -exec cp -vt ./bin/ -- {} +
cd bin
rm *.sample *.sh
sudo cp * /usr/sbin/
ptp4l -v
4.4-00039-gddeec0f-dirty
ls /usr/share/doc/linuxptp/configs/automotive-*.cfg
Here’s a config I’ve seen used.
/etc/linuxptp/automotive-slave.cfg
[global]
# IEEE 802.1AS / Automotive Profile — time-aware end station (slave)
gmCapable 0
priority1 248
priority2 248
# Hardware timestamping
time_stamping hardware
tx_timestamp_timeout 20
network_transport L2
delay_mechanism P2P
transportSpecific 0x1
ptp_dst_mac 01:80:C2:00:00:0E
# gPTP
logSyncInterval -3
syncReceiptTimeout 3
neighborPropDelayThresh 800
min_neighbor_prop_delay -20000000
assume_two_step 1
path_trace_enabled 1
follow_up_info 1
# Automotive Profile (static roles, no BMCA)
BMCA noop
clientOnly 1 # use 'slaveOnly 1' if staying on older linuxptp.
inhibit_announce 1
asCapable true
ignore_source_id 1
# Interval negotiation once the servo is locked
operLogSyncInterval 0
operLogPdelayReqInterval 2
msg_interval_request 1
# Servo
clock_servo pi
step_threshold 1 # step on GM time jumps > 1 s
servo_offset_threshold 30 # ns
servo_num_offset_values 10
# Logging
summary_interval 4 # summary every 16 s
fault_reset_interval 1
[eqos_0]
Hi @SivaRamaKrishnaNV
Could you test using DOS 7.2.5 release if there is no dependency on DOS 7.0.3?
Unfortunately, our system will be using DOS 7.0.3 only.
So ethernet is connected to eqos interface and trying to sync system clock to eqos clock using phc2sys causing offset to go beyond 0.4 msec and comes back to normal. Is my understanding correct?
Yes. eqos_0 is connected to time server and eqos_0 is synced with time server. phc2sys is then trying to sync system clock to eqos_0 and large offsets are observed sometimes.
Can this be reproduced using phc2sys -s eqos_0 -c CLOCK_REALTIME -O 0 -S 1.0 on with ethernet connected to eqos interface?
For our system we have designated eqos_0 as the interface to the time server. Hence system clock is synced with eqos_0 and nvpps is also synced with eqos_0. I don’t think the exact interface matters so long as you do phc2sys -s <interface that nvpps uses> -c CLOCK_REALTIME -O 0 -S 1.0.
Hi @whitesscott
What version linuxptp binaries are you using?
We’re using v4.0
Will upgrading to v4.4 fix this issue?
It may be worth trying; takes literally seconds to compile. You could backup the binaries, see if it helps, if not revert.
cd /usr/sbin
cp -p hwstamp_ctl nsm phc2sys phc_ctl pmc ptp4l timemaster ts2phc tz2alt /tmp
Build linuxptp
cp hwstamp_ctl nsm phc2sys phc_ctl pmc ptp4l timemaster ts2phc tz2alt /usr/sbin/
On my plain Thor dev kit Jetpack 7.2.1 I had to stop/restart ptp4l-mgbe0_0.service to be able to copy ptp4l.
