From: Harlan Stenn Date: Sun, 17 Aug 2008 10:57:54 +0000 (-0400) Subject: Documentation updates from Dave Mills X-Git-Tag: NTP_4_2_5P124~1 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=058f5daa9a1f73189074ca0e89b5108b832c5d44;p=thirdparty%2Fntp.git Documentation updates from Dave Mills bk: 48a80432dm-FPB9uR3WaqMJrr2E7Mg --- diff --git a/ChangeLog b/ChangeLog index 267cdd451..7de85bbb3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,4 @@ +* Documentation updates from Dave Mills. * Include (4.2.4p5) 2008/08/17 Released by Harlan Stenn * [Bug 861] leap info was not being transmitted. * [Bug 1046] refnumtoa.c is using the wrong header file. diff --git a/html/ntpd.html b/html/ntpd.html index 983381108..a8d3185b6 100644 --- a/html/ntpd.html +++ b/html/ntpd.html @@ -57,7 +57,17 @@

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 The NTP Timescale and Leap Seconds white paper

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.

Additional Features

-

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 NTP Interleaved Modes page. 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 clients at the same time. Further details are in the white paper NTP Interleaved On-Wire Protocol and the briefing of the same name.

+

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 NTP + Interleaved Modes page. 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 clients at the same time. Further details are in the + white paper NTP + Interleaved On-Wire Protocol and the briefing Interleaved + Synchroization Protocols for LANs and Space Data Links.

If ntpd, is configured with NetInfo support, it will attempt to read its configuration from the NetInfo service if the default ntp.conf file cannot be read and no file is specified by the -c option.

In contexts where a host name is expected, a -4 qualifier preceding the host name forces DNS resolution to the IPv4 namespace, while a -6 qualifier forces DNS resolution to the IPv6 namespace.

Various internal ntpd variables can be displayed and configuration options altered while the ntpd is running using the ntpq and ntpdc utility programs.

diff --git a/html/xleave.html b/html/xleave.html index bacfd640a..767448d25 100644 --- a/html/xleave.html +++ b/html/xleave.html @@ -18,10 +18,17 @@

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 (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 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.

+

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 or 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 clients at the same time. Further details are in the white paper NTP Interleaved On-Wire Protocol and the briefing of the same name.

+

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.

gif