[ntp:questions] Idea to improve ntpd accuracy

Miroslav Lichvar mlichvar at redhat.com
Fri Feb 26 08:32:39 UTC 2016


On Thu, Feb 25, 2016 at 01:52:03PM -0800, Weber wrote:
> The NIC generates an interrupt after the packet is sent which can result in
> a fairly accurate trailing hardstamp. The problem is...the packet is already
> gone and has the wrong transmit timestamp.

ntpd actually supports an "interleave" mode that was designed for
this. It allows exchange of timestamps that were captured after the
packet was sent. But it can work only in the symmetric (peers) and
broadcast mode. For the ordinary client/server mode there is nothing
like that.

> What if the poll response packet contained a flag or indication of some sort
> which means "this is an approximate transmit timestamp". That packet would
> then be immediately followed by a second response packet with a more
> accurate transmit time. The second packet could be otherwise identical to
> the first, or it could be a new flavor of packet that contained only the
> transmit time (that would save on network bandwidth).

This could work, but there would be a problem with traffic
amplification. For one request packet there would be two packets in
reply. In PTP, which was designed for local networks, it doesn't
really matter, but if it should work over internet, this would need to
be addressed. One option would be to require a large extension field
in the request. The server would still send twice as many packets, but
at least the amount of traffic would be similar in both directions. A
better solution might be saving the follow-up timestamps on the server
in some buffer and the client would ask for it with a separate
request.

Another approach to get accurate tx timestamps is to implement a
"one-step" NTP server using the launch time feature that's present on
some NICs. Instead of capturing the timestamp after the packet is
sent, the time of the transmission can be set in advance and there is
no need for a follow-up.

If there was an extension field to account for delays in the
processing of the packet on the network path between the client and
server, and it was supported in switches/routers similarly to PTP,
sub-microsecond accuracy would be possible.

-- 
Miroslav Lichvar


More information about the questions mailing list