+* [Bug 2241] MDNS registration should only happen if requested.
(4.2.7p290) 2012/07/20 Released by Harlan Stenn <stenn@ntp.org>
* [Bug 1454] Add parse clock support for the SEL-240x GPS products.
* CID 709185: refclock_chu.c will leak fd==0 (better fix)
<dd>Specify the name and path of the symmetric key file, default <tt>/etc/ntp.keys</tt>. This is the same operation as the <tt>keys <i>keyfile</i></tt> command.</dd>
<dt><tt>-l <i>logfile</i></tt></dt>
<dd>Specify the name and path of the log file. The default is the system log file. This is the same operation as the <tt>logfile <i>logfile</i></tt> command.</dd>
+ <dt id="--mdns"><tt>-m</tt></dt>
+ <dd>Once the system clock is synchronized, register with mDNS as an available server.</dd>
<dt id="--novirtualips"><tt>-L</tt></dt>
<dd>Do not listen to virtual interfaces, defined as those with names containing a colon. This option is deprecated. Please consider using the configuration file <a href="miscopt.html#interface">interface</a> command, which is more versatile.</dd>
<dt><tt>-M</tt></dt>
/*
* EDIT THIS FILE WITH CAUTION (ntpd-opts.c)
*
- * It has been AutoGen-ed July 20, 2012 at 12:00:32 AM by AutoGen 5.14
+ * It has been AutoGen-ed July 26, 2012 at 06:17:48 PM by AutoGen 5.14
* From the definitions ntpd-opts.def
* and the template file options
*
/*
* ntpd option static const strings
*/
-static char const ntpd_opt_strs[3008] =
+static char const ntpd_opt_strs[3053] =
/* 0 */ "ntpd 4.2.7p290\n"
"Copyright (C) 1970-2012 The University of Delaware, all rights reserved.\n"
"This is free software. It is licensed for use, modification and\n"
"documentation for any purpose with or without fee is hereby granted,\n"
"provided that the above copyright notice appears in all copies and that\n"
"both the copyright notice and this permission notice appear in supporting\n"
- "documentation, and that the name The University of Delaware not be used in\n"
- "advertising or publicity pertaining to distribution of the software\n"
+ "documentation, and that the name The University of Delaware not be used\n"
+ "in advertising or publicity pertaining to distribution of the software\n"
"without specific, written prior permission. The University of Delaware\n"
"makes no representations about the suitability this software for any\n"
"purpose. It is provided \"as is\" without express or implied warranty.\n\0"
/* 2611 */ "Force CPU cycle counter use (Windows only)\0"
/* 2654 */ "PCCFREQ\0"
/* 2662 */ "pccfreq\0"
-/* 2670 */ "Display extended usage information and exit\0"
-/* 2714 */ "help\0"
-/* 2719 */ "Extended usage information passed thru pager\0"
-/* 2764 */ "more-help\0"
-/* 2774 */ "Output version information and exit\0"
-/* 2810 */ "version\0"
-/* 2818 */ "NTPD\0"
-/* 2823 */ "ntpd - NTP daemon program - Ver. 4.2.7p290\n"
+/* 2670 */ "Register with mDNS as a NTP server\0"
+/* 2705 */ "MDNS\0"
+/* 2710 */ "mdns\0"
+/* 2715 */ "Display extended usage information and exit\0"
+/* 2759 */ "help\0"
+/* 2764 */ "Extended usage information passed thru pager\0"
+/* 2809 */ "more-help\0"
+/* 2819 */ "Output version information and exit\0"
+/* 2855 */ "version\0"
+/* 2863 */ "NTPD\0"
+/* 2868 */ "ntpd - NTP daemon program - Ver. 4.2.7p290\n"
"USAGE: %s [ -<flag> [<val>] | --<name>[{=| }<val>] ]... \\\n"
"\t\t[ <server1> ... <serverN> ]\n\0"
-/* 2956 */ "http://bugs.ntp.org, bugs@ntp.org\0"
-/* 2990 */ "\n\n\0"
-/* 2993 */ "ntpd 4.2.7p290";
+/* 3001 */ "http://bugs.ntp.org, bugs@ntp.org\0"
+/* 3035 */ "\n\n\0"
+/* 3038 */ "ntpd 4.2.7p290";
/*
* ipv4 option description with
#define PCCFREQ_name NULL
#endif /* SYS_WINNT */
+/*
+ * mdns option description:
+ */
+#ifdef HAVE_DNSREGISTRATION
+#define MDNS_DESC (ntpd_opt_strs+2670)
+#define MDNS_NAME (ntpd_opt_strs+2705)
+#define MDNS_name (ntpd_opt_strs+2710)
+#define MDNS_FLAGS (OPTST_DISABLED)
+
+#else /* disable mdns */
+#define MDNS_FLAGS (OPTST_OMITTED | OPTST_NO_INIT)
+#define MDNS_NAME NULL
+#define MDNS_DESC NULL
+#define MDNS_name NULL
+#endif /* HAVE_DNSREGISTRATION */
+
/*
* Help/More_Help/Version option descriptions:
*/
-#define HELP_DESC (ntpd_opt_strs+2670)
-#define HELP_name (ntpd_opt_strs+2714)
+#define HELP_DESC (ntpd_opt_strs+2715)
+#define HELP_name (ntpd_opt_strs+2759)
#ifdef HAVE_WORKING_FORK
-#define MORE_HELP_DESC (ntpd_opt_strs+2719)
-#define MORE_HELP_name (ntpd_opt_strs+2764)
+#define MORE_HELP_DESC (ntpd_opt_strs+2764)
+#define MORE_HELP_name (ntpd_opt_strs+2809)
#define MORE_HELP_FLAGS (OPTST_IMM | OPTST_NO_INIT)
#else
#define MORE_HELP_DESC NULL
# define VER_FLAGS (OPTST_SET_ARGTYPE(OPARG_TYPE_STRING) | \
OPTST_ARG_OPTIONAL | OPTST_IMM | OPTST_NO_INIT)
#endif
-#define VER_DESC (ntpd_opt_strs+2774)
-#define VER_name (ntpd_opt_strs+2810)
+#define VER_DESC (ntpd_opt_strs+2819)
+#define VER_name (ntpd_opt_strs+2855)
/*
* Declare option callback procedures
*/
/* desc, NAME, name */ PCCFREQ_DESC, PCCFREQ_NAME, PCCFREQ_name,
/* disablement strs */ NULL, NULL },
+ { /* entry idx, value */ 33, VALUE_OPT_MDNS,
+ /* equiv idx, value */ 33, VALUE_OPT_MDNS,
+ /* equivalenced to */ NO_EQUIVALENT,
+ /* min, max, act ct */ 0, 1, 0,
+ /* opt state flags */ MDNS_FLAGS, 0,
+ /* last opt argumnt */ { NULL }, /* --mdns */
+ /* arg list/cookie */ NULL,
+ /* must/cannot opts */ NULL, NULL,
+ /* option proc */ NULL,
+ /* desc, NAME, name */ MDNS_DESC, MDNS_NAME, MDNS_name,
+ /* disablement strs */ NULL, NULL },
+
{ /* entry idx, value */ INDEX_OPT_VERSION, VALUE_OPT_VERSION,
/* equiv idx value */ NO_EQUIVALENT, VALUE_OPT_VERSION,
/* equivalenced to */ NO_EQUIVALENT,
*
* Define the Ntpd Option Environment
*/
-#define zPROGNAME (ntpd_opt_strs+2818)
-#define zUsageTitle (ntpd_opt_strs+2823)
+#define zPROGNAME (ntpd_opt_strs+2863)
+#define zUsageTitle (ntpd_opt_strs+2868)
#define zRcName NULL
#define apzHomeList NULL
-#define zBugsAddr (ntpd_opt_strs+2956)
-#define zExplain (ntpd_opt_strs+2990)
+#define zBugsAddr (ntpd_opt_strs+3001)
+#define zExplain (ntpd_opt_strs+3035)
#define zDetail (NULL)
-#define zFullVersion (ntpd_opt_strs+2993)
+#define zFullVersion (ntpd_opt_strs+3038)
/* extracted from optcode.tlib near line 315 */
#if defined(ENABLE_NLS)
NO_EQUIVALENT, /* '-#' option index */
NO_EQUIVALENT /* index of default opt */
},
- 36 /* full option count */, 33 /* user option count */,
+ 37 /* full option count */, 34 /* user option count */,
ntpd_full_usage, ntpd_short_usage,
NULL, NULL,
PKGDATADIR, ntpd_packager_info
/*
* EDIT THIS FILE WITH CAUTION (ntpd-opts.h)
*
- * It has been AutoGen-ed July 20, 2012 at 12:00:31 AM by AutoGen 5.14
+ * It has been AutoGen-ed July 26, 2012 at 06:17:48 PM by AutoGen 5.14
* From the definitions ntpd-opts.def
* and the template file options
*
INDEX_OPT_SLEW = 30,
INDEX_OPT_USEPCC = 31,
INDEX_OPT_PCCFREQ = 32,
- INDEX_OPT_VERSION = 33,
- INDEX_OPT_HELP = 34,
- INDEX_OPT_MORE_HELP = 35
+ INDEX_OPT_MDNS = 33,
+ INDEX_OPT_VERSION = 34,
+ INDEX_OPT_HELP = 35,
+ INDEX_OPT_MORE_HELP = 36
} teOptIndex;
-#define OPTION_CT 36
+#define OPTION_CT 37
#define NTPD_VERSION "4.2.7p290"
#define NTPD_FULL_VERSION "ntpd 4.2.7p290"
# warning undefining PCCFREQ due to option name conflict
# undef PCCFREQ
# endif
+# ifdef MDNS
+# warning undefining MDNS due to option name conflict
+# undef MDNS
+# endif
#else /* NO_OPTION_NAME_WARNINGS */
# undef IPV4
# undef IPV6
# undef SLEW
# undef USEPCC
# undef PCCFREQ
+# undef MDNS
#endif /* NO_OPTION_NAME_WARNINGS */
/* * * * * *
#define VALUE_OPT_SLEW 'x'
#define VALUE_OPT_USEPCC 31
#define VALUE_OPT_PCCFREQ 32
+#define VALUE_OPT_MDNS 'm'
#define VALUE_OPT_HELP '?'
#define VALUE_OPT_MORE_HELP '!'
#define VALUE_OPT_VERSION INDEX_OPT_VERSION
#
# EDIT THIS FILE WITH CAUTION (ntpd-opts.texi)
#
-# It has been AutoGen-ed July 20, 2012 at 12:01:38 AM by AutoGen 5.14
+# It has been AutoGen-ed July 26, 2012 at 06:19:51 PM by AutoGen 5.14
# From the definitions ntpd-opts.def
# and the template file aginfo.tpl
@end ignore
* ntpd jaildir:: jaildir option (-i)
* ntpd keyfile:: keyfile option (-k)
* ntpd logfile:: logfile option (-l)
+* ntpd mdns:: mdns option (-m)
* ntpd modifymmtimer:: modifymmtimer option (-M)
* ntpd nice:: nice option (-N)
* ntpd nofork:: nofork option (-n)
quit
saveconfigquit
-x no slew Slew up to 600 seconds
- -! opt version Output version information and exit
+ -" opt version Output version information and exit
-? no help Display extended usage information and exit
-! no more-help Extended usage information passed thru pager
logfile logfile
configuration file directive.
+@node ntpd mdns
+@subsection mdns option (-m)
+@cindex ntpd-mdns
+
+This is the ``register with mdns as a ntp server'' option.
+
+This option has some usage constraints. It:
+@itemize @bullet
+@item
+must be compiled in by defining @code{HAVE_DNSREGISTRATION} during the compilation.
+@end itemize
+
+Registers as an NTP server with the local mDNS server which allows
+the server to be discovered via mDNS client lookup.
+
@node ntpd modifymmtimer
@subsection modifymmtimer option (-M)
@cindex ntpd-modifymmtimer
-.TH ntpd 1ntpdman "20 Jul 2012" "4.2.7p290" "User Commands"
+.TH ntpd 1ntpdman "26 Jul 2012" "4.2.7p290" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpd-opts.man)
.\"
-.\" It has been AutoGen-ed July 20, 2012 at 12:01:33 AM by AutoGen 5.14
+.\" It has been AutoGen-ed July 26, 2012 at 06:19:47 PM by AutoGen 5.14
.\" From the definitions ntpd-opts.def
.\" and the template file agman-cmd.tpl
.\"
.RB [ \-\fIflag\fP " [\fIvalue\fP]]... [" \-\-\fIopt\-name\fP " [[=| ]\fIvalue\fP]]..." [ <server1> ... <serverN> ]
.PP
.SH DESCRIPTION
-The
-.B
-utility is an operating system daemon which sets
-and maintains the system time of day in synchronism with Internet
-standard time servers.
-It is a complete implementation of the
-Network Time Protocol (NTP) version 4, as defined by RFC-5905,
-but also retains compatibility with
-version 3, as defined by RFC-1305, and versions 1
-and 2, as defined by RFC-1059 and RFC-1119, respectively.
-.PP
-The
-.B
-utility does most computations in 64-bit floating point
-arithmetic and does relatively clumsy 64-bit fixed point operations
-only when necessary to preserve the ultimate precision, about 232
-picoseconds.
-While the ultimate precision is not achievable with
-ordinary workstations and networks of today, it may be required
-with future gigahertz CPU clocks and gigabit LANs.
-.PP
-Ordinarily,
-.B
-reads the
-.Xr ntp.conf 5
-configuration file at startup time in order to determine the
-synchronization sources and operating modes.
-It is also possible to
-specify a working, although limited, configuration entirely on the
-command line, obviating the need for a configuration file.
-This may
-be particularly useful when the local host is to be configured as a
-broadcast/multicast client, with all peers being determined by
-listening to broadcasts at run time.
-.PP
-If NetInfo support is built into
-.B ,
-then
-.B
-will attempt to read its configuration from the
-NetInfo if the default
-.Xr ntp.conf 5
-file cannot be read and no file is
-specified by the
-c
-option.
-.PP
-Various internal
-.B
-variables can be displayed and
-configuration options altered while the
-.B
-is running
-using the
-.Xr ntpq 8
-and
-.Xr ntpdc 8
-utility programs.
-.PP
-When
-.B
-starts it looks at the value of
-.Xr umask 2 ,
-and if zero
-.B
-will set the
-.Xr umask 2
-to 022.
+#! /usr/local/gnu/bin/cat
.SH "OPTIONS"
.TP
.BR \-4 ", " -\-ipv4
The CPU counter (RDTSC on x86) is used unconditionally with the
given frequency (in Hz).
.TP
+.BR \-m ", " -\-mdns
+Register with mDNS as a NTP server.
+.sp
+Registers as an NTP server with the local mDNS server which allows
+the server to be discovered via mDNS client lookup.
+.TP
.BR \-? , " \-\-help"
Display usage information and exit.
.TP
.fi
.ad
.SH USAGE
-.Ss "How NTP Operates"
-The
-.B
-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
-.Cm iburst
-keyword with the
-.Ic server
-configuration
-command, as described in
-.Xr ntp.conf 5 .
-.PP
-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
-.B
-detects that the time on the host
-is more than 1000s from the server time,
-.B
-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
-.B
-to exit with a panic message to
-the system log.
-The
-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
-.B
-to exit anyway.
-.PP
-Under ordinary conditions,
-.B
-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
-.B
-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.
-.PP
-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
-.B
-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
-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
-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.
-.PP
-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,
-.B
-enters the same state as when the
-.Pa 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
-.Cm 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
-.Cm burst
-keyword when
-configuring the server, but
-ONLY
-when you have permission to do so from the owner of the target host.
-.PP
-Finally,
-in the past many startup scripts would run
-.Xr ntpdate 8
-to get the system clock close to correct before starting
-.Xr ntpd 8 ,
-but this was never more than a mediocre hack and is no longer needed.
-.PP
-There is a way to start
-.Xr ntpd 8
-that often addresses all of the problems mentioned above.
-.Ss "Starting NTP (Best Current Practice)"
-First, use the
-.Cm iburst
-option on your
-.Cm server
-entries.
-.PP
-If you can also keep a good
-.Pa ntp.drift
-file then
-.Xr ntpd 8
-will effectively "warm-start" and your system's clock will
-be stable in under 11 seconds' time.
-.PP
-As soon as possible in the startup sequence, start
-.Xr ntpd 8
-with at least the
-g
-and perhaps the
-N
-options.
-Then,
-start the rest of your "normal" processes.
-This will give
-.Xr ntpd 8
-as much time as possible to get the system's clock synchronized and stable.
-.PP
-Finally,
-if you have processes like
-.Cm dovecot
-or database servers
-that require
-monotonically-increasing time,
-run
-.Xr ntp-wait 8
-as late as possible in the boot sequence
-(perhaps with the
-v
-flag)
-and after
-.Xr ntp-wait 8
-exits successfully
-it is as safe as it will ever be to start any process that require
-stable time.
-.Ss "Frequency Discipline"
-The
-.B
-behavior at startup depends on whether the
-frequency file, usually
-.Pa ntp.drift ,
-exists.
-This file
-contains the latest estimate of clock frequency error.
-When the
-.B
-is started and the file does not exist, the
-.B
-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
-.B
-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
-.B
-is started and the file does exist, the
-.B
-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.
-.Ss "Operating Modes"
-The
-.B
-utility can operate in any of several modes, including
-symmetric active/passive, client/server broadcast/multicast and
-manycast, as described in the
-.Qq Association Management
-page
-(available as part of the HTML documentation
-provided in
-.Pa /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.
-.PP
-By default,
-.B
-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.
-.PP
-In some cases it may not be practical for
-.B
-to run
-continuously.
-A common workaround has been to run the
-.Xr ntpdate 8
-program from a
-.Xr cron 8
-job at designated
-times.
-However, this program does not have the crafted signal
-processing, error checking and mitigation algorithms of
-.B .
-The
-q
-option is intended for this purpose.
-Setting this option will cause
-.B
-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
-.Cm iburst
-keyword with the
-.Ic 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
-.Xr ntpdate 8
-program may be
-retired.
-.PP
-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,
-.B
-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
-.B
-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.
-.Ss "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
-.Ic tinker
-.Cm minpoll
-command to a value not less than 16 s.
-This value is used for all
-configured associations, unless overridden by the
-.Cm 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.
-.PP
-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
-.Pa 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.
-.Ss "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.
-.PP
-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.
-.PP
-The filter is activated by the
-.Ic tinker
-command and
-.Cm huffpuff
-keyword, as described in
-.Xr ntp.conf 5 .
+#! /usr/local/gnu/bin/cat
.SH "ENVIRONMENT"
See \fBOPTION PRESETS\fP for configuration environment variables.
.SH FILES
-.TP
-.BR Pa /etc/ntp.conf
-the default name of the configuration file
-.TP
-.BR Pa /etc/ntp.drift
-the default name of the drift file
-.TP
-.BR Pa /etc/ntp.keys
-the default name of the key file
+#! /usr/local/gnu/bin/cat
.SH "EXIT STATUS"
One of the following exit values will be returned:
.TP
.BR 1
The operation failed or the command syntax was not valid.
.SH "SEE ALSO"
-.Xr ntp.conf 5 ,
-.Xr ntpdate 8 ,
-.Xr ntpdc 8 ,
-.Xr ntpq 8
-.PP
-In addition to the manual pages provided,
-comprehensive documentation is available on the world wide web
-at
-.Li http://www.ntp.org/ .
-A snapshot of this documentation is available in HTML format in
-.Pa /usr/share/doc/ntp .
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 1)
-.%O RFC1059
-.Re
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 2)
-.%O RFC1119
-.Re
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 3)
-.%O RFC1305
-.Re
-.Rs
-.%A David L. Mills
-.%A J. Martin, Ed.
-.%A J. Burbank
-.%A W. Kasch
-.%T Network Time Protocol Version 4: Protocol and Algorithms Specification
-.%O RFC5905
-.Re
-.Rs
-.%A David L. Mills
-.%A B. Haberman, Ed.
-.%T Network Time Protocol Version 4: Autokey Specification
-.%O RFC5906
-.Re
-.Rs
-.%A H. Gerstung
-.%A C. Elliott
-.%A B. Haberman, Ed.
-.%T Definitions of Managed Objects for Network Time Protocol Version 4: (NTPv4)
-.%O RFC5907
-.Re
-.Rs
-.%A R. Gayraud
-.%A B. Lourdelet
-.%T Network Time Protocol (NTP) Server Option for DHCPv6
-.%O RFC5908
-.Re
+#! /usr/local/gnu/bin/cat
.SH "AUTHORS"
The University of Delaware
.SH "COPYRIGHT"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.SH BUGS
-The
-.B
-utility has gotten rather fat.
-While not huge, it has gotten
-larger than might be desirable for an elevated-priority
-.B
-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.Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
+#! /usr/local/gnu/bin/catPlease send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.SH NOTES
-Portions of this document came from FreeBSD..Pp
+#! /usr/local/gnu/bin/cat.Pp
This manual page was \fIAutoGen\fP-erated from the \fBntpd\fP
option definitions.
-.Dd July 20 2012
+.Dd July 26 2012
.Dt NTPD 1ntpdmdoc User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpd-opts.mdoc)
.\"
-.\" It has been AutoGen-ed July 20, 2012 at 12:01:39 AM by AutoGen 5.14
+.\" It has been AutoGen-ed July 26, 2012 at 06:19:51 PM by AutoGen 5.14
.\" From the definitions ntpd-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
[ <server1> ... <serverN> ]
.Pp
.Sh DESCRIPTION
-The
-.Nm
-utility is an operating system daemon which sets
-and maintains the system time of day in synchronism with Internet
-standard time servers.
-It is a complete implementation of the
-Network Time Protocol (NTP) version 4, as defined by RFC-5905,
-but also retains compatibility with
-version 3, as defined by RFC-1305, and versions 1
-and 2, as defined by RFC-1059 and RFC-1119, respectively.
-.Pp
-The
-.Nm
-utility does most computations in 64-bit floating point
-arithmetic and does relatively clumsy 64-bit fixed point operations
-only when necessary to preserve the ultimate precision, about 232
-picoseconds.
-While the ultimate precision is not achievable with
-ordinary workstations and networks of today, it may be required
-with future gigahertz CPU clocks and gigabit LANs.
-.Pp
-Ordinarily,
-.Nm
-reads the
-.Xr ntp.conf 5
-configuration file at startup time in order to determine the
-synchronization sources and operating modes.
-It is also possible to
-specify a working, although limited, configuration entirely on the
-command line, obviating the need for a configuration file.
-This may
-be particularly useful when the local host is to be configured as a
-broadcast/multicast client, with all peers being determined by
-listening to broadcasts at run time.
-.Pp
-If NetInfo support is built into
-.Nm ,
-then
-.Nm
-will attempt to read its configuration from the
-NetInfo if the default
-.Xr ntp.conf 5
-file cannot be read and no file is
-specified by the
-.Fl c
-option.
-.Pp
-Various internal
-.Nm
-variables can be displayed and
-configuration options altered while the
-.Nm
-is running
-using the
-.Xr ntpq 8
-and
-.Xr ntpdc 8
-utility programs.
-.Pp
-When
-.Nm
-starts it looks at the value of
-.Xr umask 2 ,
-and if zero
-.Nm
-will set the
-.Xr umask 2
-to 022.
+#! /usr/local/gnu/bin/cat
.Sh "OPTIONS"
.Bl -tag
.It \-4 ", " -\-ipv4
Force substitution the CPU counter for QueryPerformanceCounter.
The CPU counter (RDTSC on x86) is used unconditionally with the
given frequency (in Hz).
+.It \-m ", " -\-mdns
+Register with mDNS as a NTP server.
+.sp
+Registers as an NTP server with the local mDNS server which allows
+the server to be discovered via mDNS client lookup.
.It \-? , " \-\-help"
Display usage information and exit.
.It \-! , " \-\-more-help"
.fi
.ad
.Sh USAGE
-.Ss "How NTP Operates"
-The
-.Nm
-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
-.Cm iburst
-keyword with the
-.Ic server
-configuration
-command, as described in
-.Xr ntp.conf 5 .
-.Pp
-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
-.Nm
-detects that the time on the host
-is more than 1000s from the server time,
-.Nm
-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
-.Nm
-to exit with a panic message to
-the system log.
-The
-.Fl 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
-.Nm
-to exit anyway.
-.Pp
-Under ordinary conditions,
-.Nm
-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
-.Nm
-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.
-.Pp
-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
-.Nm
-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
-.Fl 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
-.Fl 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.
-.Pp
-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,
-.Nm
-enters the same state as when the
-.Pa 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
-.Cm 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
-.Cm burst
-keyword when
-configuring the server, but
-ONLY
-when you have permission to do so from the owner of the target host.
-.Pp
-Finally,
-in the past many startup scripts would run
-.Xr ntpdate 8
-to get the system clock close to correct before starting
-.Xr ntpd 8 ,
-but this was never more than a mediocre hack and is no longer needed.
-.Pp
-There is a way to start
-.Xr ntpd 8
-that often addresses all of the problems mentioned above.
-.Ss "Starting NTP (Best Current Practice)"
-First, use the
-.Cm iburst
-option on your
-.Cm server
-entries.
-.Pp
-If you can also keep a good
-.Pa ntp.drift
-file then
-.Xr ntpd 8
-will effectively "warm-start" and your system's clock will
-be stable in under 11 seconds' time.
-.Pp
-As soon as possible in the startup sequence, start
-.Xr ntpd 8
-with at least the
-.Fl g
-and perhaps the
-.Fl N
-options.
-Then,
-start the rest of your "normal" processes.
-This will give
-.Xr ntpd 8
-as much time as possible to get the system's clock synchronized and stable.
-.Pp
-Finally,
-if you have processes like
-.Cm dovecot
-or database servers
-that require
-monotonically-increasing time,
-run
-.Xr ntp-wait 8
-as late as possible in the boot sequence
-(perhaps with the
-.Fl v
-flag)
-and after
-.Xr ntp-wait 8
-exits successfully
-it is as safe as it will ever be to start any process that require
-stable time.
-.Ss "Frequency Discipline"
-The
-.Nm
-behavior at startup depends on whether the
-frequency file, usually
-.Pa ntp.drift ,
-exists.
-This file
-contains the latest estimate of clock frequency error.
-When the
-.Nm
-is started and the file does not exist, the
-.Nm
-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
-.Nm
-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
-.Nm
-is started and the file does exist, the
-.Nm
-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.
-.Ss "Operating Modes"
-The
-.Nm
-utility can operate in any of several modes, including
-symmetric active/passive, client/server broadcast/multicast and
-manycast, as described in the
-.Qq Association Management
-page
-(available as part of the HTML documentation
-provided in
-.Pa /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.
-.Pp
-By default,
-.Nm
-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.
-.Pp
-In some cases it may not be practical for
-.Nm
-to run
-continuously.
-A common workaround has been to run the
-.Xr ntpdate 8
-program from a
-.Xr cron 8
-job at designated
-times.
-However, this program does not have the crafted signal
-processing, error checking and mitigation algorithms of
-.Nm .
-The
-.Fl q
-option is intended for this purpose.
-Setting this option will cause
-.Nm
-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
-.Cm iburst
-keyword with the
-.Ic 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
-.Xr ntpdate 8
-program may be
-retired.
-.Pp
-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,
-.Nm
-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
-.Nm
-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.
-.Ss "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
-.Ic tinker
-.Cm minpoll
-command to a value not less than 16 s.
-This value is used for all
-configured associations, unless overridden by the
-.Cm 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.
-.Pp
-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
-.Pa 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.
-.Ss "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.
-.Pp
-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.
-.Pp
-The filter is activated by the
-.Ic tinker
-command and
-.Cm huffpuff
-keyword, as described in
-.Xr ntp.conf 5 .
+#! /usr/local/gnu/bin/cat
.Sh "ENVIRONMENT"
See \fBOPTION PRESETS\fP for configuration environment variables.
.Sh FILES
-.Bl -tag -width /etc/ntp.drift -compact
-.It Pa /etc/ntp.conf
-the default name of the configuration file
-.It Pa /etc/ntp.drift
-the default name of the drift file
-.It Pa /etc/ntp.keys
-the default name of the key file
-.El
+#! /usr/local/gnu/bin/cat
.Sh "EXIT STATUS"
One of the following exit values will be returned:
.Bl -tag
The operation failed or the command syntax was not valid.
.El
.Sh "SEE ALSO"
-.Xr ntp.conf 5 ,
-.Xr ntpdate 8 ,
-.Xr ntpdc 8 ,
-.Xr ntpq 8
-.Pp
-In addition to the manual pages provided,
-comprehensive documentation is available on the world wide web
-at
-.Li http://www.ntp.org/ .
-A snapshot of this documentation is available in HTML format in
-.Pa /usr/share/doc/ntp .
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 1)
-.%O RFC1059
-.Re
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 2)
-.%O RFC1119
-.Re
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 3)
-.%O RFC1305
-.Re
-.Rs
-.%A David L. Mills
-.%A J. Martin, Ed.
-.%A J. Burbank
-.%A W. Kasch
-.%T Network Time Protocol Version 4: Protocol and Algorithms Specification
-.%O RFC5905
-.Re
-.Rs
-.%A David L. Mills
-.%A B. Haberman, Ed.
-.%T Network Time Protocol Version 4: Autokey Specification
-.%O RFC5906
-.Re
-.Rs
-.%A H. Gerstung
-.%A C. Elliott
-.%A B. Haberman, Ed.
-.%T Definitions of Managed Objects for Network Time Protocol Version 4: (NTPv4)
-.%O RFC5907
-.Re
-.Rs
-.%A R. Gayraud
-.%A B. Lourdelet
-.%T Network Time Protocol (NTP) Server Option for DHCPv6
-.%O RFC5908
-.Re
+#! /usr/local/gnu/bin/cat
.Sh "AUTHORS"
The University of Delaware
.Sh "COPYRIGHT"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.Sh BUGS
-The
-.Nm
-utility has gotten rather fat.
-While not huge, it has gotten
-larger than might be desirable for an elevated-priority
-.Nm
-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.Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
+#! /usr/local/gnu/bin/catPlease send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.Sh NOTES
-Portions of this document came from FreeBSD..Pp
+#! /usr/local/gnu/bin/cat.Pp
This manual page was \fIAutoGen\fP-erated from the \fBntpd\fP
option definitions.
* after we have synched the first time. If the attempt fails, then try again once per
* minute for up to 5 times. After all, we may be starting before mDNS.
*/
-int mdnsreg = TRUE;
+int mdnsreg = FALSE;
int mdnstries = 5;
#endif /* HAVE_DNSREGISTRATION */
set_mm_timer(MM_TIMER_HIRES);
# endif
+#ifdef HAVE_DNSREGISTRATION
+/*
+ * Enable mDNS registrations?
+ */
+ if (HAVE_OPT( MDNS )) {
+ mdnsreg = TRUE;
+ }
+#endif /* HAVE_DNSREGISTRATION */
+
if (HAVE_OPT( NOVIRTUALIPS ))
listen_to_virtual_ips = 0;
}
} else {
msyslog(LOG_INFO, "mDNS service registered.");
- mdnsreg = 0;
+ mdnsreg = FALSE;
}
}
# endif /* HAVE_DNSREGISTRATION */
-.TH ntpd @NTPD_MS@ "20 Jul 2012" "4.2.7p290" "User Commands"
+.TH ntpd @NTPD_MS@ "26 Jul 2012" "4.2.7p290" "User Commands"
.\"
.\" EDIT THIS FILE WITH CAUTION (ntpd-opts.man)
.\"
-.\" It has been AutoGen-ed July 20, 2012 at 12:01:33 AM by AutoGen 5.14
+.\" It has been AutoGen-ed July 26, 2012 at 06:19:47 PM by AutoGen 5.14
.\" From the definitions ntpd-opts.def
.\" and the template file agman-cmd.tpl
.\"
.RB [ \-\fIflag\fP " [\fIvalue\fP]]... [" \-\-\fIopt\-name\fP " [[=| ]\fIvalue\fP]]..." [ <server1> ... <serverN> ]
.PP
.SH DESCRIPTION
-The
-.B
-utility is an operating system daemon which sets
-and maintains the system time of day in synchronism with Internet
-standard time servers.
-It is a complete implementation of the
-Network Time Protocol (NTP) version 4, as defined by RFC-5905,
-but also retains compatibility with
-version 3, as defined by RFC-1305, and versions 1
-and 2, as defined by RFC-1059 and RFC-1119, respectively.
-.PP
-The
-.B
-utility does most computations in 64-bit floating point
-arithmetic and does relatively clumsy 64-bit fixed point operations
-only when necessary to preserve the ultimate precision, about 232
-picoseconds.
-While the ultimate precision is not achievable with
-ordinary workstations and networks of today, it may be required
-with future gigahertz CPU clocks and gigabit LANs.
-.PP
-Ordinarily,
-.B
-reads the
-.Xr ntp.conf 5
-configuration file at startup time in order to determine the
-synchronization sources and operating modes.
-It is also possible to
-specify a working, although limited, configuration entirely on the
-command line, obviating the need for a configuration file.
-This may
-be particularly useful when the local host is to be configured as a
-broadcast/multicast client, with all peers being determined by
-listening to broadcasts at run time.
-.PP
-If NetInfo support is built into
-.B ,
-then
-.B
-will attempt to read its configuration from the
-NetInfo if the default
-.Xr ntp.conf 5
-file cannot be read and no file is
-specified by the
-c
-option.
-.PP
-Various internal
-.B
-variables can be displayed and
-configuration options altered while the
-.B
-is running
-using the
-.Xr ntpq 8
-and
-.Xr ntpdc 8
-utility programs.
-.PP
-When
-.B
-starts it looks at the value of
-.Xr umask 2 ,
-and if zero
-.B
-will set the
-.Xr umask 2
-to 022.
+#! /usr/local/gnu/bin/cat
.SH "OPTIONS"
.TP
.BR \-4 ", " -\-ipv4
The CPU counter (RDTSC on x86) is used unconditionally with the
given frequency (in Hz).
.TP
+.BR \-m ", " -\-mdns
+Register with mDNS as a NTP server.
+.sp
+Registers as an NTP server with the local mDNS server which allows
+the server to be discovered via mDNS client lookup.
+.TP
.BR \-? , " \-\-help"
Display usage information and exit.
.TP
.fi
.ad
.SH USAGE
-.Ss "How NTP Operates"
-The
-.B
-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
-.Cm iburst
-keyword with the
-.Ic server
-configuration
-command, as described in
-.Xr ntp.conf 5 .
-.PP
-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
-.B
-detects that the time on the host
-is more than 1000s from the server time,
-.B
-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
-.B
-to exit with a panic message to
-the system log.
-The
-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
-.B
-to exit anyway.
-.PP
-Under ordinary conditions,
-.B
-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
-.B
-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.
-.PP
-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
-.B
-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
-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
-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.
-.PP
-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,
-.B
-enters the same state as when the
-.Pa 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
-.Cm 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
-.Cm burst
-keyword when
-configuring the server, but
-ONLY
-when you have permission to do so from the owner of the target host.
-.PP
-Finally,
-in the past many startup scripts would run
-.Xr ntpdate 8
-to get the system clock close to correct before starting
-.Xr ntpd 8 ,
-but this was never more than a mediocre hack and is no longer needed.
-.PP
-There is a way to start
-.Xr ntpd 8
-that often addresses all of the problems mentioned above.
-.Ss "Starting NTP (Best Current Practice)"
-First, use the
-.Cm iburst
-option on your
-.Cm server
-entries.
-.PP
-If you can also keep a good
-.Pa ntp.drift
-file then
-.Xr ntpd 8
-will effectively "warm-start" and your system's clock will
-be stable in under 11 seconds' time.
-.PP
-As soon as possible in the startup sequence, start
-.Xr ntpd 8
-with at least the
-g
-and perhaps the
-N
-options.
-Then,
-start the rest of your "normal" processes.
-This will give
-.Xr ntpd 8
-as much time as possible to get the system's clock synchronized and stable.
-.PP
-Finally,
-if you have processes like
-.Cm dovecot
-or database servers
-that require
-monotonically-increasing time,
-run
-.Xr ntp-wait 8
-as late as possible in the boot sequence
-(perhaps with the
-v
-flag)
-and after
-.Xr ntp-wait 8
-exits successfully
-it is as safe as it will ever be to start any process that require
-stable time.
-.Ss "Frequency Discipline"
-The
-.B
-behavior at startup depends on whether the
-frequency file, usually
-.Pa ntp.drift ,
-exists.
-This file
-contains the latest estimate of clock frequency error.
-When the
-.B
-is started and the file does not exist, the
-.B
-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
-.B
-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
-.B
-is started and the file does exist, the
-.B
-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.
-.Ss "Operating Modes"
-The
-.B
-utility can operate in any of several modes, including
-symmetric active/passive, client/server broadcast/multicast and
-manycast, as described in the
-.Qq Association Management
-page
-(available as part of the HTML documentation
-provided in
-.Pa /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.
-.PP
-By default,
-.B
-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.
-.PP
-In some cases it may not be practical for
-.B
-to run
-continuously.
-A common workaround has been to run the
-.Xr ntpdate 8
-program from a
-.Xr cron 8
-job at designated
-times.
-However, this program does not have the crafted signal
-processing, error checking and mitigation algorithms of
-.B .
-The
-q
-option is intended for this purpose.
-Setting this option will cause
-.B
-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
-.Cm iburst
-keyword with the
-.Ic 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
-.Xr ntpdate 8
-program may be
-retired.
-.PP
-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,
-.B
-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
-.B
-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.
-.Ss "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
-.Ic tinker
-.Cm minpoll
-command to a value not less than 16 s.
-This value is used for all
-configured associations, unless overridden by the
-.Cm 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.
-.PP
-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
-.Pa 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.
-.Ss "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.
-.PP
-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.
-.PP
-The filter is activated by the
-.Ic tinker
-command and
-.Cm huffpuff
-keyword, as described in
-.Xr ntp.conf 5 .
+#! /usr/local/gnu/bin/cat
.SH "ENVIRONMENT"
See \fBOPTION PRESETS\fP for configuration environment variables.
.SH FILES
-.TP
-.BR Pa /etc/ntp.conf
-the default name of the configuration file
-.TP
-.BR Pa /etc/ntp.drift
-the default name of the drift file
-.TP
-.BR Pa /etc/ntp.keys
-the default name of the key file
+#! /usr/local/gnu/bin/cat
.SH "EXIT STATUS"
One of the following exit values will be returned:
.TP
.BR 1
The operation failed or the command syntax was not valid.
.SH "SEE ALSO"
-.Xr ntp.conf 5 ,
-.Xr ntpdate 8 ,
-.Xr ntpdc 8 ,
-.Xr ntpq 8
-.PP
-In addition to the manual pages provided,
-comprehensive documentation is available on the world wide web
-at
-.Li http://www.ntp.org/ .
-A snapshot of this documentation is available in HTML format in
-.Pa /usr/share/doc/ntp .
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 1)
-.%O RFC1059
-.Re
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 2)
-.%O RFC1119
-.Re
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 3)
-.%O RFC1305
-.Re
-.Rs
-.%A David L. Mills
-.%A J. Martin, Ed.
-.%A J. Burbank
-.%A W. Kasch
-.%T Network Time Protocol Version 4: Protocol and Algorithms Specification
-.%O RFC5905
-.Re
-.Rs
-.%A David L. Mills
-.%A B. Haberman, Ed.
-.%T Network Time Protocol Version 4: Autokey Specification
-.%O RFC5906
-.Re
-.Rs
-.%A H. Gerstung
-.%A C. Elliott
-.%A B. Haberman, Ed.
-.%T Definitions of Managed Objects for Network Time Protocol Version 4: (NTPv4)
-.%O RFC5907
-.Re
-.Rs
-.%A R. Gayraud
-.%A B. Lourdelet
-.%T Network Time Protocol (NTP) Server Option for DHCPv6
-.%O RFC5908
-.Re
+#! /usr/local/gnu/bin/cat
.SH "AUTHORS"
The University of Delaware
.SH "COPYRIGHT"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.SH BUGS
-The
-.B
-utility has gotten rather fat.
-While not huge, it has gotten
-larger than might be desirable for an elevated-priority
-.B
-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.Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
+#! /usr/local/gnu/bin/catPlease send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.SH NOTES
-Portions of this document came from FreeBSD..Pp
+#! /usr/local/gnu/bin/cat.Pp
This manual page was \fIAutoGen\fP-erated from the \fBntpd\fP
option definitions.
-.Dd July 20 2012
+.Dd July 26 2012
.Dt NTPD @NTPD_MS@ User Commands
.Os SunOS 5.10
.\" EDIT THIS FILE WITH CAUTION (ntpd-opts.mdoc)
.\"
-.\" It has been AutoGen-ed July 20, 2012 at 12:01:39 AM by AutoGen 5.14
+.\" It has been AutoGen-ed July 26, 2012 at 06:19:51 PM by AutoGen 5.14
.\" From the definitions ntpd-opts.def
.\" and the template file agmdoc-cmd.tpl
.Sh NAME
[ <server1> ... <serverN> ]
.Pp
.Sh DESCRIPTION
-The
-.Nm
-utility is an operating system daemon which sets
-and maintains the system time of day in synchronism with Internet
-standard time servers.
-It is a complete implementation of the
-Network Time Protocol (NTP) version 4, as defined by RFC-5905,
-but also retains compatibility with
-version 3, as defined by RFC-1305, and versions 1
-and 2, as defined by RFC-1059 and RFC-1119, respectively.
-.Pp
-The
-.Nm
-utility does most computations in 64-bit floating point
-arithmetic and does relatively clumsy 64-bit fixed point operations
-only when necessary to preserve the ultimate precision, about 232
-picoseconds.
-While the ultimate precision is not achievable with
-ordinary workstations and networks of today, it may be required
-with future gigahertz CPU clocks and gigabit LANs.
-.Pp
-Ordinarily,
-.Nm
-reads the
-.Xr ntp.conf 5
-configuration file at startup time in order to determine the
-synchronization sources and operating modes.
-It is also possible to
-specify a working, although limited, configuration entirely on the
-command line, obviating the need for a configuration file.
-This may
-be particularly useful when the local host is to be configured as a
-broadcast/multicast client, with all peers being determined by
-listening to broadcasts at run time.
-.Pp
-If NetInfo support is built into
-.Nm ,
-then
-.Nm
-will attempt to read its configuration from the
-NetInfo if the default
-.Xr ntp.conf 5
-file cannot be read and no file is
-specified by the
-.Fl c
-option.
-.Pp
-Various internal
-.Nm
-variables can be displayed and
-configuration options altered while the
-.Nm
-is running
-using the
-.Xr ntpq 8
-and
-.Xr ntpdc 8
-utility programs.
-.Pp
-When
-.Nm
-starts it looks at the value of
-.Xr umask 2 ,
-and if zero
-.Nm
-will set the
-.Xr umask 2
-to 022.
+#! /usr/local/gnu/bin/cat
.Sh "OPTIONS"
.Bl -tag
.It \-4 ", " -\-ipv4
Force substitution the CPU counter for QueryPerformanceCounter.
The CPU counter (RDTSC on x86) is used unconditionally with the
given frequency (in Hz).
+.It \-m ", " -\-mdns
+Register with mDNS as a NTP server.
+.sp
+Registers as an NTP server with the local mDNS server which allows
+the server to be discovered via mDNS client lookup.
.It \-? , " \-\-help"
Display usage information and exit.
.It \-! , " \-\-more-help"
.fi
.ad
.Sh USAGE
-.Ss "How NTP Operates"
-The
-.Nm
-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
-.Cm iburst
-keyword with the
-.Ic server
-configuration
-command, as described in
-.Xr ntp.conf 5 .
-.Pp
-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
-.Nm
-detects that the time on the host
-is more than 1000s from the server time,
-.Nm
-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
-.Nm
-to exit with a panic message to
-the system log.
-The
-.Fl 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
-.Nm
-to exit anyway.
-.Pp
-Under ordinary conditions,
-.Nm
-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
-.Nm
-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.
-.Pp
-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
-.Nm
-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
-.Fl 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
-.Fl 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.
-.Pp
-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,
-.Nm
-enters the same state as when the
-.Pa 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
-.Cm 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
-.Cm burst
-keyword when
-configuring the server, but
-ONLY
-when you have permission to do so from the owner of the target host.
-.Pp
-Finally,
-in the past many startup scripts would run
-.Xr ntpdate 8
-to get the system clock close to correct before starting
-.Xr ntpd 8 ,
-but this was never more than a mediocre hack and is no longer needed.
-.Pp
-There is a way to start
-.Xr ntpd 8
-that often addresses all of the problems mentioned above.
-.Ss "Starting NTP (Best Current Practice)"
-First, use the
-.Cm iburst
-option on your
-.Cm server
-entries.
-.Pp
-If you can also keep a good
-.Pa ntp.drift
-file then
-.Xr ntpd 8
-will effectively "warm-start" and your system's clock will
-be stable in under 11 seconds' time.
-.Pp
-As soon as possible in the startup sequence, start
-.Xr ntpd 8
-with at least the
-.Fl g
-and perhaps the
-.Fl N
-options.
-Then,
-start the rest of your "normal" processes.
-This will give
-.Xr ntpd 8
-as much time as possible to get the system's clock synchronized and stable.
-.Pp
-Finally,
-if you have processes like
-.Cm dovecot
-or database servers
-that require
-monotonically-increasing time,
-run
-.Xr ntp-wait 8
-as late as possible in the boot sequence
-(perhaps with the
-.Fl v
-flag)
-and after
-.Xr ntp-wait 8
-exits successfully
-it is as safe as it will ever be to start any process that require
-stable time.
-.Ss "Frequency Discipline"
-The
-.Nm
-behavior at startup depends on whether the
-frequency file, usually
-.Pa ntp.drift ,
-exists.
-This file
-contains the latest estimate of clock frequency error.
-When the
-.Nm
-is started and the file does not exist, the
-.Nm
-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
-.Nm
-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
-.Nm
-is started and the file does exist, the
-.Nm
-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.
-.Ss "Operating Modes"
-The
-.Nm
-utility can operate in any of several modes, including
-symmetric active/passive, client/server broadcast/multicast and
-manycast, as described in the
-.Qq Association Management
-page
-(available as part of the HTML documentation
-provided in
-.Pa /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.
-.Pp
-By default,
-.Nm
-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.
-.Pp
-In some cases it may not be practical for
-.Nm
-to run
-continuously.
-A common workaround has been to run the
-.Xr ntpdate 8
-program from a
-.Xr cron 8
-job at designated
-times.
-However, this program does not have the crafted signal
-processing, error checking and mitigation algorithms of
-.Nm .
-The
-.Fl q
-option is intended for this purpose.
-Setting this option will cause
-.Nm
-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
-.Cm iburst
-keyword with the
-.Ic 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
-.Xr ntpdate 8
-program may be
-retired.
-.Pp
-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,
-.Nm
-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
-.Nm
-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.
-.Ss "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
-.Ic tinker
-.Cm minpoll
-command to a value not less than 16 s.
-This value is used for all
-configured associations, unless overridden by the
-.Cm 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.
-.Pp
-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
-.Pa 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.
-.Ss "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.
-.Pp
-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.
-.Pp
-The filter is activated by the
-.Ic tinker
-command and
-.Cm huffpuff
-keyword, as described in
-.Xr ntp.conf 5 .
+#! /usr/local/gnu/bin/cat
.Sh "ENVIRONMENT"
See \fBOPTION PRESETS\fP for configuration environment variables.
.Sh FILES
-.Bl -tag -width /etc/ntp.drift -compact
-.It Pa /etc/ntp.conf
-the default name of the configuration file
-.It Pa /etc/ntp.drift
-the default name of the drift file
-.It Pa /etc/ntp.keys
-the default name of the key file
-.El
+#! /usr/local/gnu/bin/cat
.Sh "EXIT STATUS"
One of the following exit values will be returned:
.Bl -tag
The operation failed or the command syntax was not valid.
.El
.Sh "SEE ALSO"
-.Xr ntp.conf 5 ,
-.Xr ntpdate 8 ,
-.Xr ntpdc 8 ,
-.Xr ntpq 8
-.Pp
-In addition to the manual pages provided,
-comprehensive documentation is available on the world wide web
-at
-.Li http://www.ntp.org/ .
-A snapshot of this documentation is available in HTML format in
-.Pa /usr/share/doc/ntp .
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 1)
-.%O RFC1059
-.Re
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 2)
-.%O RFC1119
-.Re
-.Rs
-.%A David L. Mills
-.%T Network Time Protocol (Version 3)
-.%O RFC1305
-.Re
-.Rs
-.%A David L. Mills
-.%A J. Martin, Ed.
-.%A J. Burbank
-.%A W. Kasch
-.%T Network Time Protocol Version 4: Protocol and Algorithms Specification
-.%O RFC5905
-.Re
-.Rs
-.%A David L. Mills
-.%A B. Haberman, Ed.
-.%T Network Time Protocol Version 4: Autokey Specification
-.%O RFC5906
-.Re
-.Rs
-.%A H. Gerstung
-.%A C. Elliott
-.%A B. Haberman, Ed.
-.%T Definitions of Managed Objects for Network Time Protocol Version 4: (NTPv4)
-.%O RFC5907
-.Re
-.Rs
-.%A R. Gayraud
-.%A B. Lourdelet
-.%T Network Time Protocol (NTP) Server Option for DHCPv6
-.%O RFC5908
-.Re
+#! /usr/local/gnu/bin/cat
.Sh "AUTHORS"
The University of Delaware
.Sh "COPYRIGHT"
Copyright (C) 1970-2012 The University of Delaware all rights reserved.
This program is released under the terms of the NTP license, <http://ntp.org/license>.
.Sh BUGS
-The
-.Nm
-utility has gotten rather fat.
-While not huge, it has gotten
-larger than might be desirable for an elevated-priority
-.Nm
-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.Please send bug reports to: http://bugs.ntp.org, bugs@ntp.org
+#! /usr/local/gnu/bin/catPlease send bug reports to: http://bugs.ntp.org, bugs@ntp.org
.Sh NOTES
-Portions of this document came from FreeBSD..Pp
+#! /usr/local/gnu/bin/cat.Pp
This manual page was \fIAutoGen\fP-erated from the \fBntpd\fP
option definitions.
given frequency (in Hz).
_EndOfDoc_;
};
+
+flag = {
+ ifdef = HAVE_DNSREGISTRATION;
+ name = mdns;
+ value = m;
+ descrip = "Register with mDNS as a NTP server";
+ doc = <<- _EndOfDoc_
+ Registers as an NTP server with the local mDNS server which allows
+ the server to be discovered via mDNS client lookup.
+ _EndOfDoc_;
+};
projects / thirdparty / ntp.git / commitdiff
