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
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
