Annotation of embedaddon/ntp/html/xleave.html, revision 1.1.1.1
1.1 misho 1: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
2:
3: <html>
4:
5: <head>
6: <meta http-equiv="content-type" content="text/html;charset=iso-8859-1">
7: <meta name="generator" content="HTML Tidy, see www.w3.org">
8: <title>NTP Interleaved Modes</title>
9: <link href="scripts/style.css" type="text/css" rel="stylesheet">
10: </head>
11:
12: <body>
13: <h3>NTP Interleaved Modes </h3>
14: <img src="pic/pogo4.gif" alt="gif" align="left"><a href="http://www.eecis.udel.edu/%7emills/pictures.html">from <i>Pogo</i>, Walt Kelly</a>
15: <p>You need a little magic.</p>
16: <p>Last update:
17: <!-- #BeginDate format:En2m -->03-May-2009 3:37<!-- #EndDate -->
18: UTC</p>
19: <br clear="left">
20: <hr>
21: <p>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.</p>
22: <p> 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.</p>
23: <p>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 <font face="symbol">m</font>s for a dual-core, 2.8 GHz Pentium 4 running FreeBSD 6.1 to 1100 <font face="symbol">m</font>s for a Sun Blade 1500 running Solaris 10.</p>
24: <p>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 <font face="symbol">m</font>s. On two identical Pentium 4 machines in symmetric mode, the measured output delay is 16 <font face="symbol">m</font>s and remaining one-way delay components 45-150 <font face="symbol">m</font>s. Two LAN segments account for 20 <font face="symbol">m</font>s, which leaves 25-130 <font face="symbol">m</font>s for input delay. On two identical UltraSPARC machines running Solaris 10 in symmetric mode, the measured output delay is 160 <font face="symbol">m</font>s and remaining one-way delay components 195 <font face="symbol">m</font>s. Two LAN segments account for 20 <font face="symbol">m</font>s, which leaves 175 ms for input delay.</p>
25: <p>Performance with the Pentia show a residual jitter of about 20 <font face="symbol">m</font>s, 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 <font face="symbol">m</font>s.</p>
26: <p>Interleaved modes can be used only in NTP symmetric and broadcast modes.
27: It is activated by the <tt>xleave</tt> option with the <tt>peer</tt> or <tt>broadcast</tt> configuration
28: commands. The NTP protocol automatically reconfigures in normal or
29: interleaved mode as required. Ordinary broadcast clients can use
30: the same servers as interleaved broadcast clients at the same time.
31: Further details are in the white paper <a href="http://www.eecis.udel.edu/~mills/onwire.html">NTP
32: Interleaved On-Wire Protocol</a> and the briefing <a href="http://www.eecis.udel.edu/~mills/database/brief/onwire/onwire.ppt">Interleaved
33: Synchronization Protocols for LANs and Space Data Links</a>.</p>
34: <hr>
35: <div align="center">
36: <img src="pic/pogo1a.gif" alt="gif">
37: </div>
38: <br>
39: <script type="text/javascript" language="javascript" src="scripts/footer.txt"></script>
40: </body>
41:
42: </html>
FreeBSD-CVSweb <freebsd-cvsweb@FreeBSD.org>
![[BACK]](/icons/cvsweb/back.gif){kind=icon}
Return to xleave.html CVS log ![[TXT]](/icons/cvsweb/text.gif){kind=icon}
![[DIR]](/icons/cvsweb/dir.gif){kind=icon}
Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / ntp / html