From: Harlan Stenn Date: Mon, 27 Jan 2014 09:42:49 +0000 (+0000) Subject: html/ cleanup X-Git-Tag: NTP_4_2_7P413~5 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=febb84f5f23441f19ab3d949bdf1d2f88a9a6b65;p=thirdparty%2Fntp.git html/ cleanup bk: 52e62a19uwy79uehwXDNbKTlV5s1JQ --- diff --git a/ChangeLog b/ChangeLog index fce1464ce..e8d61c32c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,4 @@ +* html/ cleanup (4.2.7p412) 2014/01/20 Released by Harlan Stenn * [Bug 2540] bootstrap script needs to 'touch' files in finer-grained groups. (4.2.7p411) 2014/01/12 Released by Harlan Stenn diff --git a/html/assoc.html b/html/assoc.html index 386966b9b..e2cb76150 100644 --- a/html/assoc.html +++ b/html/assoc.html @@ -53,7 +53,7 @@

As symmetric modes are most often used as root servers for moderate to large subnets where rapid response is required, it is generally best to set the minimum and maximum poll intervals of each root server to the same value using the minpoll and maxpoll options.

Broadcast/Multicast Modes

NTP broadcast and multicast modes are intended for configurations involving one or a few servers and a possibly very large client population. Broadcast mode can be used with Ethernet, FDDI and WiFi spans interconnected by hubs or switches. Ordinarily, broadcast packets do not extend beyond a level-3 router. Where service is intended beyond a level-3 router, multicast mode can be used. Additional information is on the Automatic NTP Configuration Options page.

-

A server is configured to send broadcast or multicast messages using the broadcast command and specifying the subnet address for broadcast or the multicast group address for multicast. A broadcast client is enabled using the broadcastclient command, while a multicast client is enabled using the multicastclient command and specifying the multicast group address. Multiple commands of either type can be used. However, the association is not mobilized until the first broadcast or multicast message is actually received.

+

A server is configured to send broadcast or multicast messages using the broadcast command and specifying the subnet address for broadcast or the multicast group address for multicast. A broadcast client is enabled using the broadcastclient command, while a multicast client is enabled using the multicastclient command and specifying the multicast group address. Multiple commands of either type can be used. However, the association is not mobilized until the first broadcast or multicast message is actually received.

Manycast and Pool Modes

Manycast and pool modes are automatic discovery and configuration paradigms new to NTPv4. They are intended as a means for a client to troll the nearby network neighborhood to find cooperating willing servers, validate them using cryptographic means and evaluate their time values with respect to other servers that might be lurking in the vicinity. The intended result is that each client mobilizes ephemeral client associations with some number of the "best" of the nearby servers, yet automatically reconfigures to sustain this number of servers should one or another fail. Additional information is on the Automatic Server Discovery Schemes page.

Poll Interval Management

diff --git a/html/drivers/driver8.html b/html/drivers/driver8.html index 39be105fc..875279f16 100644 --- a/html/drivers/driver8.html +++ b/html/drivers/driver8.html @@ -61,7 +61,7 @@
  • Schweitzer Engineering Laboratories SEL-240x clocks

    This implementation was provided and verified by SEL and Network Time Foundation + href="http://networktimefoundation.org">Network Time Foundation has an SEL-2407 in one of its development labs.

    • diff --git a/html/hints/solaris.html b/html/hints/solaris.html index 7161d5dd3..5c8b8fe65 100644 --- a/html/hints/solaris.html +++ b/html/hints/solaris.html @@ -38,7 +38,7 @@ set dosynctodr = 0

    Instead of the tick kernel variable, which many operating systems use to control microseconds added to the system time every -clock tick (c.f. Dealing +clock tick (c.f. Dealing with Frequency Tolerance Violations), Solaris has the variables nsec_per_tick and usec_per_tick.

    @@ -63,6 +63,95 @@ HREF="solaris.xtra.S99ntpd">this one, installed in /etc/init.d/ntpd with a symbol link from /etc/rc2.d/S99ntpd. + +

    Dealing with Frequency Tolerance Violations (tickadj and +Friends)

    + The NTP Version 3 specification RFC-1305 calls for a maximum + oscillator frequency tolerance of +-100 parts-per-million (PPM), which is +representative of those components suitable for use in relatively +inexpensive workstation platforms. For those platforms meeting this +tolerance, NTP will automatically compensate for the frequency errors of the +individual oscillator and no further adjustments are required, either to the +configuration file or to various kernel variables. For the NTP Version 4 +release, this tolerance has been increased to +-500 PPM.

    However, in the +case of certain notorious platforms, in particular Sun 4.1.1 systems, the +performance can be improved by adjusting the values of certain kernel +variables; in particular, tick and tickadj. The variable +tick is the increment in microseconds added to the system time on +each interval- timer interrupt, while the variable tickadj is used +by the time adjustment code as a slew rate, in microseconds per tick. When +the time is being adjusted via a call to the system routine +adjtime(), the kernel increases or reduces tick by tickadj +microseconds per tick until the specified adjustment has been +completed. Unfortunately, in most Unix implementations the tick increment +must be either zero or plus/minus exactly tickadj microseconds, +meaning that adjustments are truncated to be an integral multiple of +tickadj (this latter behaviour is a misfeature, and is the only +reason the tickadj code needs to concern itself with the internal +implementation of tickadj at all). In addition, the stock Unix +implementation considers it an error to request another adjustment before a +prior one has completed.

    Thus, to make very sure it avoids problems +related to the roundoff, the tickadj program can be used to adjust +the values of tick and tickadj. This ensures that all +adjustments given to adjtime() are an even multiple of +tickadj microseconds and computes the largest adjustment that can +be completed in the adjustment interval (using both the value of +tick and the value of tickadj) so it can avoid exceeding +this limit. It is important to note that not all systems will allow +inspection or modification of kernel variables other than at system build +time. It is also important to know that, with the current NTP tolerances, it +is rarely necessary to make these changes, but in many cases they will +substantially improve the general accuracy of the time service.

    +

    Unfortunately, the value of tickadj set by default is almost +always too large for ntpd. NTP operates by continuously making +small adjustments to the clock, usually at one-second intervals. If +tickaj is set too large, the adjustments will disappear in the +roundoff; while, if tickadj is too small, NTP will have difficulty +if it needs to make an occasional large adjustment. While the daemon itself +will read the kernel's values of these variables, it will not change the +values, even if they are unsuitable. You must do this yourself before the +daemon is started using the tickadj program included in the +./util directory of the distribution. Note that the latter program +will also compute an optimal value of tickadj for NTP use based on +the kernel's value of tick.

    The tickadj program can +reset several other kernel variables if asked. It can change the value of +tick if asked. This is handy to compensate for kernel bugs which +cause the clock to run with a very large frequency error, as with SunOS +4.1.1 systems. It can also be used to set the value of the kernel +dosynctodr variable to zero. This variable controls whether to +synchronize the system clock to the time-of-day clock, something you really +don't want to be happen when ntpd is trying to keep it under +control. In some systems, such as recent Sun Solaris kernels, the +dosynctodr variable is the only one that can be changed by the +tickadj program. In this and other modern kernels, it is not +necessary to change the other variables in any case.

    + +

    We have a report that says starting with Solaris 2.6 we should leave +dosynctodr alone.

    In order to maintain reasonable correctness +bounds, as well as reasonably good accuracy with acceptable polling +intervals, ntpd will complain if the frequency error is greater +than 500 PPM. For machines with a value of tick in the 10-ms range, +a change of one in the value of tick will change the frequency by +about 100 PPM. In order to determine the value of tick for a +particular CPU, disconnect the machine from all source s of time +(dosynctodr = 0) and record its actual time compared to an outside +source (eyeball-and-wristwatch will do) over a day or more. Multiply the +time change over the day by 0.116 and add or subtract the result to tick, +depending on whether the CPU is fast or slow. An example call to +tickadj useful on SunOS 4.1.1 is:

    + 
    +     tickadj -t 9999 -a 5 -s
+
    +which sets tick 100 PPM fast, tickadj to 5 microseconds and turns +off the clock/calendar chip fiddle. This line can be added to the rc.local configuration file to automatically set the kernel variables +at boot time.

    All this stuff about diddling kernel variables so the NTP +daemon will work is really silly. If vendors would ship machines with clocks +that kept reasonable time and would make their adjtime() system +call apply the slew it is given exactly, independent of the value of +tickadj, all this could go away. This is in fact the case on many +current Unix systems.

    +

    Solaris 2.6

    Solaris 2.6 adds support for kernel PLL timekeeping, but breaks this diff --git a/html/pic/stats.gif b/html/pic/stats.gif new file mode 100644 index 000000000..b0d0aaa31 Binary files /dev/null and b/html/pic/stats.gif differ diff --git a/html/pic/time1.gif b/html/pic/time1.gif new file mode 100644 index 000000000..88e70420f Binary files /dev/null and b/html/pic/time1.gif differ diff --git a/html/refclock.html b/html/refclock.html index 3b09e1428..08dcb9650 100644 --- a/html/refclock.html +++ b/html/refclock.html @@ -41,7 +41,7 @@

    Following is a list showing the type and title of each driver currently implemented. The compile-time identifier for each is shown in parentheses. Click on a selected type for specific description and configuration documentation, including the clock address, reference ID, driver ID, device name and serial line speed. For those drivers without specific documentation, please contact the author listed in the Copyright Notice page.

    • Type 1 Undisciplined Local Clock (LOCAL)
      • -
    • Type 2 Trak 8820 GPS Receiver (GPS_TRAK)
      • +
    • Type 2 Deprecated: was Trak 8820 GPS Receiver
    • Type 3 PSTI/Traconex 1020 WWV/WWVH Receiver (WWV_PST)
    • Type 4 Spectracom WWVB/GPS Receivers (WWVB_SPEC)
    • Type 5 TrueTime GPS/GOES/OMEGA Receivers (TRUETIME)