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

Martin Burnicki 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.
> http://www.eecis.udel.edu/~mills/ntp/html/xleave.html

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,
>> etc.
>
> 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
> authentication.

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.


Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany



More information about the questions mailing list