| If you need precise stamping, you should not take the raw hardware timestamps as final. You should go through the same procedure to translate NIC clock values into system clock values that Chronyd does. It’s not trivial, but you can find several examples of code that does this. Search for SOF_TIMESTAMPING_RX_HARDWARE and ptp_sys_offset_extended or ptp_sys_offset.
Denny
Thanks, that's very helpful. It sounds like it could cause problems if something outside of chrony is synchronizing a NIC clock used by chrony for hardware timestamping, even if it's synchronizing it to the system clock. Am I understanding that correctly? It would be nice for my application to be able to synchronize the NIC clock as well as the system clock. It's network capture related, so the most important timestamps are being done with NIC hardware timestamping.
On Tue, Oct 20, 2020 at 08:31:36PM -0500, Scott Stephens wrote:
> I'm trying to understand the use of hardware timestamps in Chrony and I
> feel like I'm missing something. I understand how user space timestamps and
> kernel software timestamps will have errors relative to the time the packet
> leaves the NIC due to thread scheduling, interrupt coalescing, and whatnot,
> and why it would be desirable to avoid those errors. But it seems to me
> that when you hardware timestamp a packet, that timestamp will reflect the
> state of the NIC's clock, not the state of the system clock, which would
> seem to be a problem if your goal is to synchronize the system clock.
chronyd tracks the time and frequency offset of the hardware clocks
relative to the system clock, so it can convert timestamps between
them without having to synchronize one clock to another.
> With PTP, you control the relationship explicitly, with ptp4l syncing the
> NIC clock to the PTP master clock, and phc2sys syncing the system clock to
> the NIC clock.
With PTP there is only one time source active at a time, so that's
easy. With NTP, there can be multiple time sources, on the same
interface or different interfaces, which can have different hardware
clocks, and they can all be combined for synchronization of the system
clock. That requires a different approach.
> I haven't found any mention of something similar in the Chrony docs, so I'm
> wondering what if anything Chrony does to NIC clocks.
Nothing. They should be free running. This has some advantages and
disadvantages.
One issue is that if you have a stratum-1 server using PPS input on a
NIC and that NIC is serving NTP to clients, the conversion between NIC
time and system time is unnecessary. It just adds jitter. There was a
patch posted on this list, or the devel list, that can configure
chronyd to use the NIC clock as the main clock, which basically makes
it work like phc2sys and ptp4l, but it's a hack. I'd like to implement
it properly, but I'm not sure how exactly yet.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.
|