-
Bug
-
Resolution: Done-Errata
-
Normal
-
rhel-9.4
-
None
-
linuxptp-4.2-3.el9
-
Yes
-
Moderate
-
ZStream, Regression
-
rhel-sst-cs-stacks
-
ssg_core_services
-
7
-
False
-
-
None
-
Red Hat Enterprise Linux
-
None
-
Approved Blocker
-
Pass
-
Automated
-
None
What were you trying to do that didn't work?
When ts2phc is configured to synchronize a PHC to a PPS signal which has timestamped both edges (0.5s pulse width) and an NMEA source is used to reject the falling edge, the detection doesn't work for NMEA delays of less than 0.25 seconds and causes a 0.5 second error for the PHC.
Some hardware can timestamp only both edges, which requires the software detection.
This issue is caused by the fix for large NMEA delays added in RHEL-23208. The larger delay is assumed for both the PPS second numbering and edge detection.
Please provide the package NVR for which bug is seen:
linuxptp-4.2-2.el9
How reproducible:
With specific hardware
Steps to reproduce
- synchronize the system clock, e.g. with NTP
- start ts2phc -l 7 -m -q -c eth0 -s nmea --ts2phc.nmea_serialport /dev/ttyUSB0 --ts2phc.extts_polarity both, where eth0 is a NIC with connected 1Hz 0.5s pulse width PPS signal and /dev/ttyUSB0 provides NMEA with a delay smaller than 0.25 seconds
- observe the offset between the system clock and eth0 using phc_ctl eth0 cmp
Expected results
offset close to 37 seconds (current TAI-UTC offset)
Actual results
offset 37.5 seconds (error of 0.5 seconds)