[ntp:questions] Slow convergence loopstats (but nice results)
martin.burnicki at meinberg.de
Thu Dec 12 12:35:34 UTC 2013
Miroslav Lichvar wrote:
> 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.
Yes, but as you say above this is only supported in peer associations
and broadcast mode, so I see no benefit for "normal" clients. :-(
> Also, there is a feature called launch time, which is supported in
> some NICs, so the follow up message is not always necessary.
OK, but if I understand correctly then the sending ntpd would have to
know that a specific interface supports this, and put the lauch time as
transmit time into the NTP packet, and schedule sending of the packet at
the predetermined point in time.
I see some potential problems here if using this with ntpd. I'm assuming
the process or task (launcher?) which has to send the packets at the
predetermined launch time is located somewhere down in the lowest levels
of the network stack. So the lanuch time determined by ntpd must be "far
enough" after the current time so that the launcher has surely received
the packet to be sent *before* the current time reaches the launch time.
If the launch time is too near in the future then the launcher might
receive a packet from ntpd after the launch time has already passed. If
the launch time is too far in the future the launcher has to queue the
packet for "a long time" before it can be sent, and there might be a
limited queue size if a large number of packets have to be sent, e.g. to
a large number of clients.
To avoid this the launcher could be aware of special NTP packets, send
each packet when a free "slot" is available on the wire, and put the
current time into each sent packet.
If this is not possible, then ntpd would have to keep track ot the
packet is has scheduled to be launched at a given time on a given
interface. Otherwise It could schedule 2 packets for different clients
with the same launch time.
And what happens if a different application schedules a different packet
on the same interface with the same launch time?
This sound pretty error-prone to me. :-(
>> 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,
> Some NICs can time stamp any packets.
OK, that's great.
>> 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
Yes, I know. Authentication is still another restriction which makes
things even more difficult.
> 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.
Agreed. I'm very impressed how good NTP can determine and compensate
varying network latencies over WAN connections with unknown network
nodes on the route.
More information about the questions