Skip to content
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

Closed
p-ogrady opened this issue Aug 26, 2024 · 0 comments · Fixed by #9
Closed

PTP timestamps, published by HSB, aren't synchonized with the host time. #4

p-ogrady opened this issue Aug 26, 2024 · 0 comments · Fixed by #9
Assignees

Comments

@p-ogrady
Copy link
Collaborator

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, the phc2sys startup 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.

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 the phc2sys command line may fix this problem but the documentation for this option doesn't address the configuration in use here.

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 p-ogrady self-assigned this Oct 25, 2024
@p-ogrady p-ogrady linked a pull request Oct 25, 2024 that will close this issue
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
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants
@p-ogrady and others