In the protocol described in the NTP specification and implemented today the transmit timestamp is captured before the MD5 digest is computed and the packet is sent, while the receive timestamp is captured after the packet is received. For enhanced accuracy it is desirable to capture the timestamps as close to the wire as possible; i.e., with hardware assist or with a modified driver.
The problem is, while the receive timestamp could in principle be piggybacked in the receive buffer, the transmit timestamp cannot ordinarily be transmitted in the same packet. A solution for this problem is the two-step or interleaved protocol described on this page and included in the the current reference implementation. In this experimental variant the transmit timestamp for one packet is actually carried in the immediately following packet. The trick, however, is to implement the interleaved protocol without changing the NTP packet header format, without compromising backwards compatibility and without compromising the error recovery properties.
Currently, the reference implementation uses only software timestamps (softstamps). The receive softstamp is captured at software interrupt time and before the buffer is queued for later processing. The reference implementation captures a softstamp before the message digest routine and another after the send-packet routine. In this design the latter timestamp can be considered most accurate, as it avoids the kernel latencies and queueing mechanisms. The difference, called the interleaved or output delay, varies from 16 ms for a dual-core, 2.8 GHz Pentium 4 running FreeBSD 6.1 to 1100 ms for a Sun Blade 1500 running Solaris 10.
Performacne varies widely between machines and network interface cards on a 100-Mb switched Ethernet where the NTP packet is about 1000 bits or 10 ms. On two identical Pentium 4 machines in symmetric mode, the measured output delay is 16 ms and remaining one-way delay components 45-150 ms. Two LAN segments account for 20 ms, which leaves 25-130 ms for input delay. On two identical UltraSPARC machines running Solaris 10 in symmetric mode, the measured output delay is 160 ms and remaining one-way delay components 195 ms. Two LAN segments account for 20 ms, which leaves 175 ms for input delay.
Performance with the Pentia show a residual jitter of about 20 ms, which is by far the best performance so far. However, much better performance could result if the input delay could be reduced or elminated with driver or hardware timestamps. Should that be done, performance should be in the same order as the the PPS and kernel discipline, which is in the order of 2 ms.
Interleaved modes can be used only in NTP symmetric and broadcast modes.
It is activated by the xleave option with the peer or broadcast configuration
commands. The NTP protocol automatically reconfigures in normal or
interleaved mode as required. Ordinary broadcast clients can use
the same servers as interleaved broadcast clients at the same time.
Further details are in the white paper NTP
Interleaved On-Wire Protocol and the briefing Interleaved
Synchronization Protocols for LANs and Space Data Links.
@
1.1.1.1
log
@Import ntp 4.2.6
@
text
@@
1.1.1.1.8.1
log
@Apply patch (requested by christos in ticket #1221):
Update ntp to 4.2.8.
@
text
@d2 1
d4 15
a18 13
NTP Interleaved Modes
In the protocol described in the NTP specification and reference implementation up to now, the transmit timestamp, which is captured before the message digest is computed and the packet queued for output, is properly called as a softstamp The receive timestamp, which is captured after the input driver interrupt routine and before the packet is queued for input, is properly called a drivestamp. For enhanced accuracy it is desirable to capture the transmit timestamp as close to the wire as possible; for example, after the output driver interrupt routine.
In other words, we would like to replace the transmit softstamp with a drivestamp, but the problem is the transmit drivestamp is available only after the packet has been sent. A solution for this problem is the two-step or interleaved protocol described on this page and included in the the current reference implementation. In interleaved modes the transmit drivestamp for one packet is actually carried in the immediately following packet. The trick, however, is to implement the interleaved protocol without changing the NTP packet header format, without compromising backwards compatibility and without compromising the error recovery properties.
The reference implementation captures a softstamp before the message digest routine and a drivestamp after the output interrupt routine. In this design the latter timestamp can be considered most accurate, as it avoids the various queuing and transmission latencies. The difference between the two timestamps, which is called the interleaved or output delay, varies from 16 μs for a dual-core Pentium running FreeBSD 6.1 to 1100 μs for a Sun Blade 1500 running Solaris 10.
Interleaved mode can be used only in NTP symmetric and broadcast modes.
It is activated by the xleave option with the peer or broadcast configuration
commands. A broadcast server configured for interleaved mode is transparent to ordinary broadcast clients, so both ordinary and interleaved broadcast clients can use the same packets. An interleaved symmetric active peer automatically switches to ordinary symmetric mode if the other peer is not capable of operation in interleaved mode.
As demonstrated in the white paper Analysis and Simulation of the NTP On-Wire Protocols, the interleaved modes have the same resistance to lost packets, duplicate packets, packets crossed in flight and protocol restarts as the ordinary modes. An application of the interleaved symmetric mode in space missions is presented in the white paper Time Synchronization for Space Data Links.
from Pogo, Walt Kelly