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

Use precise frequency for TX SYNC messages #13

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

comio
Copy link
Contributor

@comio comio commented Mar 31, 2023

The actual ptp4l implementation rearms timers after the expiration. This approach doesn't permit to have a precise TX SYNC message scheduling.
During my test the TX SYNC frequency is slightly lower the expectation (eg 15.99Hz vs 16Hz).

The following patchset uses non blocking timers and only for TX SYNC timer implements a precise periodic timer.
Before to enable the periodic timer we have to:

  • read the timer file descriptors after the expiration in order to have the expirations counter (useful for debug also);
  • avoid to touch timers with a timerfd_settime() before the read() call, this required to rearrange the fd array and split the announce and rx sync code;
  • remove timerfd_settime() on tx sync expiration.

History:
v4 Pass sanity test
v3 Small review

comio added 6 commits July 6, 2023 12:12
This patch avoid to block on a timer fd read. We already protect with
poll().
Change fd[0] with FD_EVENT and fd[1] with FD_GENERAL.
This change ensure that all timers timeouts are handled just before the
PTP message handling.
The PTP message hanlding code can performe timerfd_settime() calls that
invalidate the status of timer descriptors. This side effect is not
noticed until now because we never read from the timer descriptors.
After the timer expiration, just after the poll(), we can read fron the
timer file descriptor a 64bit value that represents the number of
expirations that have occured. This value is useful for debug. In
addition, when we use a periodic timer the timer will be locked until
the read of this value.
During a timer handling we should avoid to call timerfd_settime() on a
different timer because this call will invalidate the file descriptor,
resulting in a EGAIN when the other timer code will performe the read().

The ANNOUNCE and RX SYNC timer code just doesn't follow this rule. The
solution is to split the rearm code.
In order to obtain a precise TX SYNC frequency we need to use a periodic
timer facility instead to reconfigure the timer on every expiration.

The solution consists to configure the it_interval field of the
itimerspec structure (see timerfd_create(2) man page) only when the port
goes into Master role and avoiding to call timerfd_settime() on timer
expiration.
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 this pull request may close these issues.

1 participant