[ntp:bk-ntp-dev-send] BitKeeper diffs

Harlan Stenn stenn at whimsy.udel.edu
Sun Aug 17 10:59:39 UTC 2008


#### ChangeSet ####
2008-08-17 06:57:54-04:00, stenn at whimsy.udel.edu 
  Documentation updates from Dave Mills

==== ChangeLog ====
2008-08-17 06:57:44-04:00, stenn at whimsy.udel.edu +1 -0
  Documentation updates from Dave Mills

--- 1.206/ChangeLog	2008-08-17 06:51:20 -04:00
+++ 1.207/ChangeLog	2008-08-17 06:57:44 -04:00
@@ -1,3 +1,4 @@
+* Documentation updates from Dave Mills.
 * Include (4.2.4p5) 2008/08/17 Released by Harlan Stenn <stenn at ntp.org>
 * [Bug 861] leap info was not being transmitted.
 * [Bug 1046] refnumtoa.c is using the wrong header file.

==== html/ntpd.html ====
2008-08-17 06:57:11-04:00, stenn at whimsy.udel.edu +11 -1
  Documentation updates from Dave Mills

--- 1.44/html/ntpd.html	2008-07-16 05:11:49 -04:00
+++ 1.45/html/ntpd.html	2008-08-17 06:57:11 -04:00
@@ -57,7 +57,17 @@
 		<p>If the latest leap is in the past, nothing further is done other than to install the TAI offset. If the leap is in the future less than 28 days, the leap warning bits are set. If in the future less than 23 hours, the kernel is armed to insert one second at the end of the current day. If the kernel is enabled, the leap is done automatically at that time; otherwise, the clock is effectively stopped for one second at the leap. Additional details are in the <a href='http://www.eecis.udel.edu/~mills/leap.html'>The NTP Timescale and Leap Seconds</a> white paper</p>
 		<p>Dependent servers and clients tally the leap warning bits of surviving servers and reference clocks. When a majority of the survivors show warning, a leap is programmed at the end of the current month. During the month and day of insertion, they operate as above. In this way the leap is propagated at all dependent servers and clients.</p>
 		<h4 id="notes">Additional Features</h4>
-		<p>A new experimental feature called interleaved modes can be used  in NTP symmetric or broadcast modes. It is designed to improve accuracy by  avoiding kernel latency and queueing delay, as described on the <a href="xleave.html">NTP Interleaved Modes</a> page. It is activated by the <tt>xleave</tt> option with the <tt>peer</tt> or <tt>broadcast</tt> configuration commands. The NTP protocol automatically reconfigures in normal or interleaved mode as required. Ordinary broadcast clients can use the same servers as interleaved clients at the same time. Further details are in the white paper <a href="http://www.eecis.udel.edu/~mills/onwire.html">NTP Interleaved On-Wire Protocol</a> and the <a href="http://www.eecis.udel.edu/~mills/database/brief/onwire/onwire.ppt">briefing</a> of the same name. </p>
+		<p>A new experimental feature called interleaved modes can be used  in NTP
+			symmetric or broadcast modes. It is designed to improve accuracy
+			by avoiding kernel latency and queueing delay, as described on the <a href="xleave.html">NTP
+			Interleaved Modes</a> page. It is activated by the <tt>xleave</tt> option
+			with the <tt>peer</tt> or <tt>broadcast</tt> configuration commands. The NTP
+			protocol automatically reconfigures in normal or interleaved mode
+			as required. Ordinary broadcast clients can use the same servers
+			as interleaved clients at the same time. Further details are in the
+			white paper <a href="http://www.eecis.udel.edu/~mills/onwire.html">NTP
+			Interleaved On-Wire Protocol</a> and the briefing <a href="http://www.eecis.udel.edu/~mills/database/brief/onwire/onwire.ppt">Interleaved
+			Synchroization Protocols for LANs and Space Data Links</a>.</p>
 		<p>If <tt>ntpd</tt>, is configured with NetInfo support, it will attempt to read its configuration from the NetInfo service if the default <tt>ntp.conf</tt> file cannot be read and no file is specified by the <tt>-c</tt> option.</p>
 		<p>In contexts where a host name is expected, a <tt>-4</tt> qualifier preceding the host name forces DNS resolution to the IPv4 namespace, while a <tt>-6</tt> qualifier forces DNS resolution to the IPv6 namespace.</p>
 		<p>Various internal <tt>ntpd</tt> variables can be displayed and configuration options altered while the <tt>ntpd</tt> is running using the <tt><a href="ntpq.html">ntpq</a></tt> and <tt><a href="ntpdc.html">ntpdc</a></tt> utility programs.</p>

==== html/xleave.html ====
2008-08-17 06:57:12-04:00, stenn at whimsy.udel.edu +9 -2
  Documentation updates from Dave Mills

--- 1.1/html/xleave.html	2008-07-16 06:16:33 -04:00
+++ 1.2/html/xleave.html	2008-08-17 06:57:12 -04:00
@@ -18,10 +18,17 @@
 		<hr>
 		<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>
 		<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>
-		<p>Currently, the reference implementation uses only software timestamps (softstamp)s. 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>
+		<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>
 		<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>
 		<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>
-		<p>Interleaved modes can be used only in NTP symmetric or broadcast modes. It is activated by the <tt>xleave</tt> option with the <tt>peer</tt> or <tt>broadcast</tt> configuration commands. The NTP protocol automatically reconfigures in normal or interleaved mode as required. Ordinary broadcast clients can use the same servers as interleaved clients at the same time. Further details are in the white paper <a href="http://www.eecis.udel.edu/~mills/onwire.html">NTP Interleaved On-Wire Protocol</a> and the <a href="http://www.eecis.udel.edu/~mills/database/brief/onwire/onwire.ppt">briefing</a> of the same name. </p>
+		<p>Interleaved modes can be used only in NTP symmetric and broadcast modes.
+			It is activated by the <tt>xleave</tt> option with the <tt>peer</tt> or <tt>broadcast</tt> 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 <a href="http://www.eecis.udel.edu/~mills/onwire.html">NTP
+			Interleaved On-Wire Protocol</a> and the briefing <a href="http://www.eecis.udel.edu/~mills/database/brief/onwire/onwire.ppt">Interleaved
+			Synchronization Protocols for LANs and Space Data Links</a>.</p>
 		<hr>
 		<center>
 			<img src="pic/pogo1a.gif" alt="gif"></center>


More information about the bk-ntp-dev-send mailing list