mirror of
https://gitlab.com/chrony/chrony.git
synced 2026-01-20 21:00:20 -05:00
ntp: add alternative method of retrieving transmitted messages
When chronyd gets a kernel or hardware transmit timestamp after sending an NTP message to a server, peer, or client (using interleaved mode), it needs the address and content of the message to be able to correctly assign the timestamp to the server, peer, or client. The timestamps are processed asynchronously. The kernel provides with each timestamp the data-link frame that was timestamped, but chronyd can extract the necessary data only from plain IPv4 and IPv6 packets in Ethernet frames, possibly including VLAN tags. If the NTP packets are transmitted by a non-Ethernet device, or they are encapsulated in another layer (e.g. a WireGuard tunnel), chronyd is not able to extract the data and use the kernel or hardware transmit timestamps, having to fall back to less accurate daemon timestamps. Add an alternative method using transmit IDs assigned to each message (supported since Linux 6.13), which are provided by the kernel with the timestamp in the error queue, and map them to messages, addresses and ports saved in a ring buffer, whose size can be configured by the new maxtxbuffers directive. Fow now, set the default maxtxbuffers to 0 (disabled). If set to a non-zero value, allocate the ring buffer to the maximum size on start. As a future improvement, it could be allocated only when the extraction of the UDP payload fails, or the extracted message is not the expected NTP message. The size could grow dynamically when a transmit ID is missed.
This commit is contained in:
@@ -2881,6 +2881,38 @@ same interface (which would compete with timestamping of the server's own
|
||||
requests), increasing the timeout to 0.01 or possibly even longer might help.
|
||||
Note that the maximum timeout is limited by the NTP polling interval.
|
||||
|
||||
[[maxtxbuffers]]*maxtxbuffers* _messages_::
|
||||
When *chronyd* gets a kernel or hardware transmit timestamp after sending an
|
||||
NTP message to a server, peer, or client (using interleaved mode), it needs the
|
||||
address and content of the message to be able to correctly assign the
|
||||
timestamp to the server, peer, or client. The timestamps are processed
|
||||
asynchronously. The kernel provides with each timestamp the data-link frame
|
||||
that was timestamped, but *chronyd* can extract the necessary data only from
|
||||
plain IPv4 and IPv6 packets in Ethernet frames, possibly including VLAN tags.
|
||||
If the NTP packets are transmitted by a non-Ethernet device, or they are
|
||||
encapsulated in another layer (e.g. a WireGuard tunnel), *chronyd* is not
|
||||
able to extract the data and use the kernel or hardware transmit timestamps,
|
||||
having to fall back to less accurate daemon timestamps.
|
||||
+
|
||||
On Linux 6.13 and newer, *chronyd* supports an alternative method of processing
|
||||
kernel and hardware transmit timestamps, which works with any device that can
|
||||
provide kernel and/or hardware transmit timestamps. *chronyd* can save its
|
||||
transmitted messages with their addresses and ports in a ring buffer, each
|
||||
assigned an ID that the kernel will provide back with the timestamp. This
|
||||
transmit ID enables *chronyd* to assign the timestamp to the correct server,
|
||||
peer, or client.
|
||||
+
|
||||
The directive specifies the maximum number of messages that *chronyd* is
|
||||
allowed to save in the ring buffer. The minimum value is 0 and the maximum
|
||||
value is 1048576. It needs about 1.5 KB of allocated memory per message.
|
||||
*chronyd* will log a warning if the number of messages is insufficient for the
|
||||
actual rate of transmit timestamping. The default value is 0 (disabled).
|
||||
+
|
||||
Example:
|
||||
----
|
||||
maxtxbuffers 128
|
||||
----
|
||||
|
||||
[[keyfile]]*keyfile* _file_::
|
||||
This directive is used to specify the location of the file containing symmetric
|
||||
keys, which are shared between NTP servers and clients, or peers, in order to
|
||||
|
||||
Reference in New Issue
Block a user