-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PTP timestamps, published by HSB, aren't synchonized with the host time. #4
Comments
p-ogrady
added a commit
that referenced
this issue
Oct 25, 2024
For applications using PTP synchronization, the setup instructions show how to run phc2sys at startup, which is necessary to keep the hardware clock in the NIC synchronized with the system clock. The setup instructions rely on the default ntpdate configuration to initialize the system clock with the current real-world time. Before, the suggested phc2sys startup script doesn't properly wait for ntpdate to complete, so that when ntpdate does finish, phc2sys sees a large jump in the system time. Because phc2sys slowly adjusts the NIC clock, the time published by ptp4l will then not be synchronized with the system clock, and could take a very long time to do so. This has the effect of publishing a time with ingress data that is out-of-sync with the system time. This change request fixes the documentation to include a startup instruction that waits for ntpdate to finish before running phc2sys. See #4.
p-ogrady
added a commit
that referenced
this issue
Oct 28, 2024
For applications using PTP synchronization, the setup instructions show how to run phc2sys at startup, which is necessary to keep the hardware clock in the NIC synchronized with the system clock. The setup instructions rely on the default ntpdate configuration to initialize the system clock with the current real-world time. Before, the suggested phc2sys startup script doesn't properly wait for ntpdate to complete, so that when ntpdate does finish, phc2sys sees a large jump in the system time. Because phc2sys slowly adjusts the NIC clock, the time published by ptp4l will then not be synchronized with the system clock, and could take a very long time to do so. This has the effect of publishing a time with ingress data that is out-of-sync with the system time. This change request fixes the documentation to include a startup instruction that waits for ntpdate to finish before running phc2sys. See #4.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The user guide hardware setup instructions show how to configure the
phc2sys
tool, which ensures that the NIC time-of-day clock (which is published in PTP network messages) is synchronized with the host real-time clock. The setup instructions rely on the default ntpdate configuration to initialize the system clock with the current real-world time. As written in the user guide, thephc2sys
startup doesn't properly wait forntpdate
to complete, so that whenntpdate
does finish,phc2sys
sees a large jump in the system time. Becausephc2sys
slowly adjusts the NIC clock, the time published byptp4l
will then not be synchronized with the system clock, and could take a very long time to do so. This has the effect of publishing a time with ingress data that is out-of-sync with the system time.To verify you're in this condition, observe the output in the "sys offset" column from the command
systemctl status phc2sys-*.service
; large absolute values are an indication of this condition.To work around this, run
sudo systemctl restart phc2sys-*.service
after ntpdate is synchronized. There is some anecdotal evidence that adding "-w" to thephc2sys
command line may fix this problem but the documentation for this option doesn't address the configuration in use here.The text was updated successfully, but these errors were encountered: