daniel-p-carvalho opened a new pull request, #3791:
URL: https://github.com/apache/nuttx-apps/pull/3791
> **Depends on apache/nuttx-apps#3782 and on apache/nuttx#20148, which in
turn depends on apache/nuttx#20180. Please do not merge this PR before them.**
>
> The first seven commits below are the commits of #3782, and are reviewed
there. Until #3782 is merged they show up in this diff; only the last two
commits are new here. This PR stays a draft until then, and I will rebase it
onto `master` once #3782 is in, so that it is reduced to those two commits. The
transmit timestamps it reads only exist with the driver support of
apache/nuttx#20148; without it the daemon falls back to software timestamps, as
described below.
## Summary
With hardware timestamping, `ptpd` took the transmit time of its event
messages (`Sync`, `Delay_Req`, `Pdelay_Req`) from the clock after `sendmsg()`
returned. That is later than the frame really left, so a fast peer's reply
could appear to arrive before the request had gone, and the peer delay measured
with the peer-to-peer mechanism came out negative (about -18 µs on the board I
tested with) and was rejected. #3782 says so: on this hardware P2P needs
accurate transmit timestamps.
This PR reads the transmit timestamp from the hardware the way Linux does.
When hardware timestamping is selected on an `AF_PACKET` socket, `ptpd`
requests `SOF_TIMESTAMPING_TX_HARDWARE` for each event message, waits for the
looped-back packet on the error queue with `MSG_ERRQUEUE` and takes the
timestamp from its `SO_TIMESTAMPING` control message. The driver side of that
is apache/nuttx#20148.
### Commits
The first seven are the commits of #3782, unchanged.
8. `Retrieve hardware TX timestamps via MSG_ERRQUEUE.` Timestamps
transmitted event messages with the hardware clock instead of reading the clock
after `sendmsg()` returns.
- A transmit socket of its own, separate from the event socket, so the
error queue is not shared with received packets.
- `POLLERR` is handled separately from `POLLIN` in the main loop, and all
pending packets are drained on each wakeup.
- If the timestamp does not arrive, a software timestamp taken before the
frame is sent is used. After three consecutive failures the driver is assumed
not to provide hardware transmit timestamps, a warning is printed once and only
software timestamps are used, so a driver without support does not stall the
daemon.
- The software timestamp is taken before sending in every mode.
- A measured path delay down to -100 µs is accepted and clamped to zero,
since hardware timestamps on both ends can make a short link measure slightly
negative.
9. `Add egress latency compensation for TX timestamps.` The frame leaves the
MAC later than the moment its hardware transmit timestamp is latched, because
of the clock domain crossing and the PHY. That fixed delay is the
`egressLatency` port parameter of IEEE 1588. Adds
`CONFIG_NETUTILS_PTPD_EGRESS_LATENCY_NS` (default 0, no compensation), the `-O`
option to override it at run time and `egress_latency_ns` in `struct
ptpd_config_s`. It is the counterpart of the ingress compensation of #3782, and
software timestamps are not affected.
## Impact
- New option `-O` and `CONFIG_NETUTILS_PTPD_EGRESS_LATENCY_NS`, default 0.
`struct ptpd_config_s` gets `egress_latency_ns`; the only user in the tree is
`system/ptpd`, which is updated here.
- Only relevant with hardware timestamping (`-H`). A driver that does not
return transmit timestamps makes the daemon switch to software timestamps after
three failures, which is the behaviour of `master` apart from the point noted
below.
- The software timestamp of a transmitted event message is now taken before
`sendmsg()` in every mode, including software-only timestamping (`-S`). On the
board I tested with, `-S` gave a smaller phase error with the timestamp taken
after `sendmsg()`, as `master` does, so this part of commit 8 could be limited
to the hardware fallback if you prefer.
- The egress compensation value has not been calibrated, so the default 0
applies no correction.
## Testing
Built for `stm32f4discovery:ethraw` with `CONFIG_STM32_ETH_TIMESTAMP_TX=y`,
without errors or warnings from `ptpd`. `./tools/checkpatch.sh -g <base>..HEAD`
passes.
On hardware: a custom STM32F407 board with the STM32 Ethernet MAC and a
DP83848 PHY, over `AF_PACKET` and through a Fast Ethernet switch (`ptpd -2 -s
-p /dev/ptp0 -B -H -P -i eth0`), against a GNSS-referenced `ptp4l` Grandmaster
using the IEC/IEEE 61850-9-3 profile, with the driver support of
apache/nuttx#20148:
- `path_delay` 9265.3 ns with σ = 2.5 ns over a 20 minute run (159 samples,
no failed queries), phase offset about -2.2 µs, drift about -79.95 ppm.
- Several 5 minute runs: `path_delay` between 9.26 and 9.33 µs.
- The PPS output of the MAC, measured on an oscilloscope against the
Grandmaster's PPS, stayed within about 20 µs.
- The same series without this PR, with software transmit timestamps, gave a
negative peer delay (about -18 µs) that was rejected, so `path_delay_ns` stayed
at 0 and the phase offset was worse (about -6.7 µs against -2.4 µs).
The end-to-end mechanism (`-E`), master mode, the best master clock
algorithm, a 24 hour run and a calibrated `-O` value were not tested.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
