[ntp:questions] Slow convergence loopstats (but nice results)

Miroslav Lichvar mlichvar at redhat.com
Thu Dec 12 10:57:15 UTC 2013


On Thu, Dec 12, 2013 at 09:59:03AM +0100, Martin Burnicki wrote:
> A major problem was that the standard NTP protocol doesn't support a
> way to send the captured time stamp of a previously sent packet to
> its client, as done by the so-called followup message in PTP.

ntpd has the peer and broadcast interleave modes to send the followup
time stamps.
http://www.eecis.udel.edu/~mills/ntp/html/xleave.html

Also, there is a feature called launch time, which is supported in
some NICs, so the follow up message is not always necessary.

> I don't know if new standard NIC chips which support PTP
> timestamping can also timestamp NTP packets, but even if they do
> then in practice there's still the problem with network switches,
> etc.

Some NICs can time stamp any packets.

> There are network switches out there which are PTP-aware and also
> timestamp incoming and outgoing PTP packets to compensate the
> introduced packet delay in some way, but there are no switches
> (AFAIK) which can do this with NTP packets, so even if you used
> hardware time stamping of NTP packets on NTP end nodes the resulting
> accuracy would still be worse than with PTP.
> 
> That's too sad.

Agreed. I think it's possible to implement a HW NTP support, but there
is problem that the switch would have to keep some state about each
NTP association. If there was a standardized extension field to store
the processing delay in both directions, that wouldn't be necessary.
I'm not sure what would have to be done to not break the NTP
authentication.

A major advantage NTP has over PTP is that it knows the delay for
each measurement in the client/server and symmetric modes, which
allows it to filter out bad measurements. In PTP the delay is measured
independently (similarly to the NTP broadcast mode), so bad
measurements can't be easily ignored and it's necessary to have all
networking HW with PTP support to account for all processing delays.

-- 
Miroslav Lichvar


More information about the questions mailing list