From: Harlan Stenn Date: Sun, 6 Jan 2013 11:47:57 +0000 (+0000) Subject: NTP_4_2_7P346 X-Git-Tag: NTP_4_2_7P346^0 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=7df0d5bbc92a42348c234042e86a01fbb481e11d;p=thirdparty%2Fntp.git NTP_4_2_7P346 bk: 50e9646dM9URi2DiHaau8cf5NTcdqw --- diff --git a/ChangeLog b/ChangeLog index 27ecba740..c383ae6c2 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,4 @@ +(4.2.7p346) 2013/01/06 Released by Harlan Stenn * [Bug 1223] reorganize inclusion of sys/resource.h. (4.2.7p345) 2013/01/04 Released by Harlan Stenn * Update several .def files to use autogen-5.17 feature set. diff --git a/ntpd/invoke-ntp.conf.texi b/ntpd/invoke-ntp.conf.texi index 4b12faa36..4da19f723 100644 --- a/ntpd/invoke-ntp.conf.texi +++ b/ntpd/invoke-ntp.conf.texi @@ -6,7 +6,7 @@ # # EDIT THIS FILE WITH CAUTION (invoke-ntp.conf.texi) # -# It has been AutoGen-ed January 4, 2013 at 09:03:01 AM by AutoGen 5.17.1pre11 +# It has been AutoGen-ed January 6, 2013 at 06:44:00 AM by AutoGen 5.17.1pre14 # From the definitions ntp.conf.def # and the template file agtexi-file.tpl @end ignore diff --git a/ntpd/invoke-ntp.keys.texi b/ntpd/invoke-ntp.keys.texi index f5ad52a0a..ab93d27b0 100644 --- a/ntpd/invoke-ntp.keys.texi +++ b/ntpd/invoke-ntp.keys.texi @@ -6,7 +6,7 @@ # # EDIT THIS FILE WITH CAUTION (invoke-ntp.keys.texi) # -# It has been AutoGen-ed January 4, 2013 at 09:03:03 AM by AutoGen 5.17.1pre11 +# It has been AutoGen-ed January 6, 2013 at 06:44:03 AM by AutoGen 5.17.1pre14 # From the definitions ntp.keys.def # and the template file agtexi-file.tpl @end ignore diff --git a/ntpd/invoke-ntpd.texi b/ntpd/invoke-ntpd.texi index bedacbb1d..581bab8b7 100644 --- a/ntpd/invoke-ntpd.texi +++ b/ntpd/invoke-ntpd.texi @@ -6,7 +6,7 @@ # # EDIT THIS FILE WITH CAUTION (invoke-ntpd.texi) # -# It has been AutoGen-ed January 4, 2013 at 09:03:04 AM by AutoGen 5.17.1pre11 +# It has been AutoGen-ed January 6, 2013 at 06:44:04 AM by AutoGen 5.17.1pre14 # From the definitions ntpd-opts.def # and the template file agtexi-cmd.tpl @end ignore @@ -141,7 +141,7 @@ with a status code of 0. @exampleindent 0 @example -ntpd - NTP daemon program - Ver. 4.2.7p345 +ntpd - NTP daemon program - Ver. 4.2.7p346 USAGE: ntpd [ - [] | --[@{=| @}] ]... \ [ ... ] Flg Arg Option-Name Description @@ -698,480 +698,11 @@ The operation failed or the command syntax was not valid. @end table @node ntpd Usage @subsection ntpd Usage -@node How NTP Operates -@section How NTP Operates - - -The -@code{ntpd} -utility operates by exchanging messages with -one or more configured servers over a range of designated poll intervals. -When -started, whether for the first or subsequent times, the program -requires several exchanges from the majority of these servers so -the signal processing and mitigation algorithms can accumulate and -groom the data and set the clock. -In order to protect the network -from bursts, the initial poll interval for each server is delayed -an interval randomized over a few seconds. -At the default initial poll -interval of 64s, several minutes can elapse before the clock is -set. -This initial delay to set the clock -can be safely and dramatically reduced using the -@code{iburst} -keyword with the -@code{server} -configuration -command, as described in -@code{ntp.conf(5)}. - -Most operating systems and hardware of today incorporate a -time-of-year (TOY) chip to maintain the time during periods when -the power is off. -When the machine is booted, the chip is used to -initialize the operating system time. -After the machine has -synchronized to a NTP server, the operating system corrects the -chip from time to time. -In the default case, if -@code{ntpd} -detects that the time on the host -is more than 1000s from the server time, -@code{ntpd} -assumes something must be terribly wrong and the only -reliable action is for the operator to intervene and set the clock -by hand. -(Reasons for this include there is no TOY chip, -or its battery is dead, or that the TOY chip is just of poor quality.) -This causes -@code{ntpd} -to exit with a panic message to -the system log. -The -@code{-g} -option overrides this check and the -clock will be set to the server time regardless of the chip time -(up to 68 years in the past or future \(em -this is a limitation of the NTPv4 protocol). -However, and to protect against broken hardware, such as when the -CMOS battery fails or the clock counter becomes defective, once the -clock has been set an error greater than 1000s will cause -@code{ntpd} -to exit anyway. - -Under ordinary conditions, -@code{ntpd} -adjusts the clock in -small steps so that the timescale is effectively continuous and -without discontinuities. -Under conditions of extreme network -congestion, the roundtrip delay jitter can exceed three seconds and -the synchronization distance, which is equal to one-half the -roundtrip delay plus error budget terms, can become very large. -The -@code{ntpd} -algorithms discard sample offsets exceeding 128 ms, -unless the interval during which no sample offset is less than 128 -ms exceeds 900s. -The first sample after that, no matter what the -offset, steps the clock to the indicated time. -In practice this -reduces the false alarm rate where the clock is stepped in error to -a vanishingly low incidence. - -As the result of this behavior, once the clock has been set it -very rarely strays more than 128 ms even under extreme cases of -network path congestion and jitter. -Sometimes, in particular when -@code{ntpd} -is first started without a valid drift file -on a system with a large intrinsic drift -the error might grow to exceed 128 ms, -which would cause the clock to be set backwards -if the local clock time is more than 128 s -in the future relative to the server. -In some applications, this behavior may be unacceptable. -There are several solutions, however. -If the -@code{-x} -option is included on the command line, the clock will -never be stepped and only slew corrections will be used. -But this choice comes with a cost that -should be carefully explored before deciding to use -the -@code{-x} -option. -The maximum slew rate possible is limited -to 500 parts-per-million (PPM) as a consequence of the correctness -principles on which the NTP protocol and algorithm design are -based. -As a result, the local clock can take a long time to -converge to an acceptable offset, about 2,000 s for each second the -clock is outside the acceptable range. -During this interval the -local clock will not be consistent with any other network clock and -the system cannot be used for distributed applications that require -correctly synchronized network time. - -In spite of the above precautions, sometimes when large -frequency errors are present the resulting time offsets stray -outside the 128-ms range and an eventual step or slew time -correction is required. -If following such a correction the -frequency error is so large that the first sample is outside the -acceptable range, -@code{ntpd} -enters the same state as when the -@file{ntp.drift} -file is not present. -The intent of this behavior -is to quickly correct the frequency and restore operation to the -normal tracking mode. -In the most extreme cases -(the host -@code{time.ien.it} -comes to mind), there may be occasional -step/slew corrections and subsequent frequency corrections. -It -helps in these cases to use the -@code{burst} -keyword when -configuring the server, but -ONLY -when you have permission to do so from the owner of the target host. - -Finally, -in the past many startup scripts would run -@code{ntpdate(8)} -to get the system clock close to correct before starting -@code{ntpd(8)}, -but this was never more than a mediocre hack and is no longer needed. - -There is a way to start -@code{ntpd(8)} -that often addresses all of the problems mentioned above. -@node Starting NTP (Best Current Practice) -@section Starting NTP (Best Current Practice) - - -First, use the -@code{iburst} -option on your -@code{server} -entries. - -If you can also keep a good -@file{ntp.drift} -file then -@code{ntpd(8)} -will effectively "warm-start" and your system's clock will -be stable in under 11 seconds' time. - -As soon as possible in the startup sequence, start -@code{ntpd(8)} -with at least the -@code{-g} -and perhaps the -@code{-N} -options. -Then, -start the rest of your "normal" processes. -This will give -@code{ntpd(8)} -as much time as possible to get the system's clock synchronized and stable. - -Finally, -if you have processes like -@code{dovecot} -or database servers -that require -monotonically-increasing time, -run -@code{ntp-wait(8)} -as late as possible in the boot sequence -(perhaps with the -@code{-v} -flag) -and after -@code{ntp-wait(8)} -exits successfully -it is as safe as it will ever be to start any process that require -stable time. -@node Frequency Discipline -@section Frequency Discipline - - -The -@code{ntpd} -behavior at startup depends on whether the -frequency file, usually -@file{ntp.drift}, -exists. -This file -contains the latest estimate of clock frequency error. -When the -@code{ntpd} -is started and the file does not exist, the -@code{ntpd} -enters a special mode designed to quickly adapt to -the particular system clock oscillator time and frequency error. -This takes approximately 15 minutes, after which the time and -frequency are set to nominal values and the -@code{ntpd} -enters -normal mode, where the time and frequency are continuously tracked -relative to the server. -After one hour the frequency file is -created and the current frequency offset written to it. -When the -@code{ntpd} -is started and the file does exist, the -@code{ntpd} -frequency is initialized from the file and enters normal mode -immediately. -After that the current frequency offset is written to -the file at hourly intervals. -@node Operating Modes -@section Operating Modes - - -The -@code{ntpd} -utility can operate in any of several modes, including -symmetric active/passive, client/server broadcast/multicast and -manycast, as described in the -"Association Management" -page -(available as part of the HTML documentation -provided in -@file{/usr/share/doc/ntp}). -It normally operates continuously while -monitoring for small changes in frequency and trimming the clock -for the ultimate precision. -However, it can operate in a one-time -mode where the time is set from an external server and frequency is -set from a previously recorded frequency file. -A -broadcast/multicast or manycast client can discover remote servers, -compute server-client propagation delay correction factors and -configure itself automatically. -This makes it possible to deploy a -fleet of workstations without specifying configuration details -specific to the local environment. - -By default, -@code{ntpd} -runs in continuous mode where each of -possibly several external servers is polled at intervals determined -by an intricate state machine. -The state machine measures the -incidental roundtrip delay jitter and oscillator frequency wander -and determines the best poll interval using a heuristic algorithm. -Ordinarily, and in most operating environments, the state machine -will start with 64s intervals and eventually increase in steps to -1024s. -A small amount of random variation is introduced in order to -avoid bunching at the servers. -In addition, should a server become -unreachable for some time, the poll interval is increased in steps -to 1024s in order to reduce network overhead. - -In some cases it may not be practical for -@code{ntpd} -to run -continuously. -A common workaround has been to run the -@code{ntpdate(8)} -program from a -@code{cron(8)} -job at designated -times. -However, this program does not have the crafted signal -processing, error checking and mitigation algorithms of -@code{ntpd}. -The -@code{-q} -option is intended for this purpose. -Setting this option will cause -@code{ntpd} -to exit just after -setting the clock for the first time. -The procedure for initially -setting the clock is the same as in continuous mode; most -applications will probably want to specify the -@code{iburst} -keyword with the -@code{server} -configuration command. -With this -keyword a volley of messages are exchanged to groom the data and -the clock is set in about 10 s. -If nothing is heard after a -couple of minutes, the daemon times out and exits. -After a suitable -period of mourning, the -@code{ntpdate(8)} -program may be -retired. - -When kernel support is available to discipline the clock -frequency, which is the case for stock Solaris, Tru64, Linux and -Fx, -a useful feature is available to discipline the clock -frequency. -First, -@code{ntpd} -is run in continuous mode with -selected servers in order to measure and record the intrinsic clock -frequency offset in the frequency file. -It may take some hours for -the frequency and offset to settle down. -Then the -@code{ntpd} -is -stopped and run in one-time mode as required. -At each startup, the -frequency is read from the file and initializes the kernel -frequency. -@node Poll Interval Control -@section Poll Interval Control - - -This version of NTP includes an intricate state machine to -reduce the network load while maintaining a quality of -synchronization consistent with the observed jitter and wander. -There are a number of ways to tailor the operation in order enhance -accuracy by reducing the interval or to reduce network overhead by -increasing it. -However, the user is advised to carefully consider -the consequences of changing the poll adjustment range from the -default minimum of 64 s to the default maximum of 1,024 s. -The -default minimum can be changed with the -@code{tinker} -@code{minpoll} -command to a value not less than 16 s. -This value is used for all -configured associations, unless overridden by the -@code{minpoll} -option on the configuration command. -Note that most device drivers -will not operate properly if the poll interval is less than 64 s -and that the broadcast server and manycast client associations will -also use the default, unless overridden. - -In some cases involving dial up or toll services, it may be -useful to increase the minimum interval to a few tens of minutes -and maximum interval to a day or so. -Under normal operation -conditions, once the clock discipline loop has stabilized the -interval will be increased in steps from the minimum to the -maximum. -However, this assumes the intrinsic clock frequency error -is small enough for the discipline loop correct it. -The capture -range of the loop is 500 PPM at an interval of 64s decreasing by a -factor of two for each doubling of interval. -At a minimum of 1,024 -s, for example, the capture range is only 31 PPM. -If the intrinsic -error is greater than this, the drift file -@file{ntp.drift} -will -have to be specially tailored to reduce the residual error below -this limit. -Once this is done, the drift file is automatically -updated once per hour and is available to initialize the frequency -on subsequent daemon restarts. -@node The huff-n'-puff Filter -@section The huff-n'-puff Filter - - -In scenarios where a considerable amount of data are to be -downloaded or uploaded over telephone modems, timekeeping quality -can be seriously degraded. -This occurs because the differential -delays on the two directions of transmission can be quite large. -In -many cases the apparent time errors are so large as to exceed the -step threshold and a step correction can occur during and after the -data transfer is in progress. - -The huff-n'-puff filter is designed to correct the apparent time -offset in these cases. -It depends on knowledge of the propagation -delay when no other traffic is present. -In common scenarios this -occurs during other than work hours. -The filter maintains a shift -register that remembers the minimum delay over the most recent -interval measured usually in hours. -Under conditions of severe -delay, the filter corrects the apparent offset using the sign of -the offset and the difference between the apparent delay and -minimum delay. -The name of the filter reflects the negative (huff) -and positive (puff) correction, which depends on the sign of the -offset. - -The filter is activated by the -@code{tinker} -command and -@code{huffpuff} -keyword, as described in -@code{ntp.conf(5)}. @node ntpd Files @subsection ntpd Files -@table @asis - -@item @file{/etc/ntp.conf} -the default name of the configuration file -@item @file{/etc/ntp.drift} -the default name of the drift file -@item @file{/etc/ntp.keys} -the default name of the key file -@end table @node ntpd See Also @subsection ntpd See Also -@code{ntp.conf(5)}, -@code{ntpdate(8)}, -@code{ntpdc(8)}, -@code{ntpq(8)} - -In addition to the manual pages provided, -comprehensive documentation is available on the world wide web -at -@code{http://www.ntp.org/}. -A snapshot of this documentation is available in HTML format in -@file{/usr/share/doc/ntp}. -@* - David L. Mills, @emph{Network Time Protocol (Version 1)}, RFC1059. -@* - David L. Mills, @emph{Network Time Protocol (Version 2)}, RFC1119. -@* - David L. Mills, @emph{Network Time Protocol (Version 3)}, RFC1305. -@* - David L. Mills, J. Martin, Ed., J. Burbank, W. Kasch, @emph{Network Time Protocol Version 4: Protocol and Algorithms Specification}, RFC5905. -@* - David L. Mills, B. Haberman, Ed., @emph{Network Time Protocol Version 4: Autokey Specification}, RFC5906. -@* - H. Gerstung, C. Elliott, B. Haberman, Ed., @emph{Definitions of Managed Objects for Network Time Protocol Version 4: (NTPv4)}, RFC5907. -@* - R. Gayraud, B. Lourdelet, @emph{Network Time Protocol (NTP) Server Option for DHCPv6}, RFC5908. @node ntpd Bugs @subsection ntpd Bugs -The -@code{ntpd} -utility has gotten rather fat. -While not huge, it has gotten -larger than might be desirable for an elevated-priority -@code{ntpd} -running on a workstation, particularly since many of -the fancy features which consume the space were designed more with -a busy primary server, rather than a high stratum workstation in -mind. @node ntpd Notes @subsection ntpd Notes -This document corresponds to version 4.2.7p345 of NTP. -Portions of this document came from FreeBSD. diff --git a/ntpd/ntp.conf.5man b/ntpd/ntp.conf.5man index 7d9eede4b..2881a523b 100644 --- a/ntpd/ntp.conf.5man +++ b/ntpd/ntp.conf.5man @@ -1,8 +1,8 @@ -.TH ntp.conf 5man "04 Jan 2013" "4.2.7p345" "File Formats" +.TH ntp.conf 5man "06 Jan 2013" "4.2.7p346" "File Formats" .\" .\" EDIT THIS FILE WITH CAUTION (ntp.man) .\" -.\" It has been AutoGen-ed January 4, 2013 at 09:02:47 AM by AutoGen 5.17.1pre11 +.\" It has been AutoGen-ed January 6, 2013 at 06:43:46 AM by AutoGen 5.17.1pre14 .\" From the definitions ntp.conf.def .\" and the template file agman-cmd.tpl .\" @@ -2950,9 +2950,12 @@ The files are really digital certificates. These should be obtained via secure directory -services when they become universally available.Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org +services when they become universally available. +.PP +Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org .SH NOTES -This document corresponds to version 4.2.7p345 of NTP. -This document was derived from FreeBSD..Pp +This document corresponds to version 4.2.7p346 of NTP. +This document was derived from FreeBSD. +.PP This manual page was \fIAutoGen\fP-erated from the \fBntp.conf\fP option definitions. diff --git a/ntpd/ntp.conf.5mdoc b/ntpd/ntp.conf.5mdoc index 40ee65c70..76a449110 100644 --- a/ntpd/ntp.conf.5mdoc +++ b/ntpd/ntp.conf.5mdoc @@ -1,9 +1,9 @@ -.Dd January 4 2013 +.Dd January 6 2013 .Dt NTP_CONF 5mdoc File Formats .Os SunOS 5.10 .\" EDIT THIS FILE WITH CAUTION (ntp.mdoc) .\" -.\" It has been AutoGen-ed January 4, 2013 at 09:03:06 AM by AutoGen 5.17.1pre11 +.\" It has been AutoGen-ed January 6, 2013 at 06:44:07 AM by AutoGen 5.17.1pre14 .\" From the definitions ntp.conf.def .\" and the template file agmdoc-cmd.tpl .Sh NAME @@ -2781,9 +2781,12 @@ The files are really digital certificates. These should be obtained via secure directory -services when they become universally available.Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org +services when they become universally available. +.Pp +Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org .Sh NOTES -This document corresponds to version 4.2.7p345 of NTP. -This document was derived from FreeBSD..Pp +This document corresponds to version 4.2.7p346 of NTP. +This document was derived from FreeBSD. +.Pp This manual page was \fIAutoGen\fP\-erated from the \fBntp.conf\fP option definitions. diff --git a/ntpd/ntp.conf.html b/ntpd/ntp.conf.html index 09b3e38bd..4c451cde7 100644 --- a/ntpd/ntp.conf.html +++ b/ntpd/ntp.conf.html @@ -33,7 +33,7 @@ Up: (dir)

This document describes the configuration file for the NTP Project's ntpd program. -

This document applies to version 4.2.7p345 of ntp.conf. +

This document applies to version 4.2.7p346 of ntp.conf.