freebsd-dev/contrib/ntp/html/miscopt.htm

280 lines
11 KiB
HTML
Raw Normal View History

2001-08-29 14:35:15 +00:00
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org">
<title>Miscellaneous Options</title>
</head>
<body>
<h3>Miscellaneous Options</h3>
<img align="left" src="pic/boom3.gif" alt="gif"><a href=
"http://www.eecis.udel.edu/~mills/pictures.htm">from <i>Pogo</i>,
Walt Kelly</a>
<p>We have three, now looking for more.<br clear="left">
</p>
<hr>
<dl>
<dt><tt>broadcastdelay <i>seconds</i></tt></dt>
<dd>The broadcast and multicast modes require a special calibration
to determine the network delay between the local and remote
servers. Ordinarily, this is done automatically by the initial
protocol exchanges between the client and server. In some cases,
the calibration procedure may fail due to network or server access
controls, for example. This command specifies the default delay to
be used under these circumstances. Typically (for Ethernet), a
number between 0.003 and 0.007 seconds is appropriate. The default
when this command is not used is 0.004 seconds.</dd>
<dt><tt>driftfile <i>driftfile</i></tt></dt>
<dd>This command specifies the name of the file used to record the
frequency offset of the local clock oscillator. If the file exists,
it is read at startup in order to set the initial frequency offset
and then updated once per hour with the current frequency offset
computed by the daemon. If the file does not exist or this command
is not given, the initial frequency offset is assumed zero. In this
case, it may take some hours for the frequency to stabilize and the
residual timing errors to subside.
<p>The file format consists of a single line containing a single
floating point number, which records the frequency offset measured
in parts-per-million (PPM). The file is updated by first writing
the current drift value into a temporary file and then renaming
this file to replace the old version. This implies that <tt>
ntpd</tt> must have write permission for the directory the drift
file is located in, and that file system links, symbolic or
otherwise, should be avoided.</p>
</dd>
<dt><tt>enable [auth | bclient | calibrate | kernel | monitor | ntp
| stats]</tt><br>
<tt>disable [auth | bclient | calibrate | kernel | monitor | ntp |
stats</tt></dt>
<dd>Provides a way to enable or disable various server options.
Flags not mentioned are unaffected. Note that all of these flags
can be controlled remotely using the <a href="ntpdc.htm"><tt>
ntpdc</tt></a> utility program.</dd>
<dd>
<dl>
<dt><tt>bclient</tt></dt>
<dd>When enabled, this is identical to the <tt>broadcastclient</tt>
command. The default for this flag is <tt>disable</tt>.</dd>
<dt><tt>calibrate</tt></dt>
<dd>Enables the calibration facility, which automatically adjusts
the <tt>time1</tt> values for each clock driver to display the same
offset as the currently selected source or kernel discipline
signal. See the <a href="refclock.htm">Reference Clock Drivers</a>
for further information. The default for this flag is <tt>
disable</tt>.</dd>
<dt><tt>kernel</tt></dt>
<dd>Enables the precision-time kernel support for the <tt>
ntp_adjtime()</tt> system call, if implemented. Ordinarily, support
for this routine is detected automatically when the NTP daemon is
compiled, so it is not necessary for the user to worry about this
flag. It flag is provided primarily so that this support can be
disabled during kernel development. The default for this flag is
<tt>enable</tt>.</dd>
<dt><tt>monitor</tt></dt>
<dd>Enables the monitoring facility. See the <tt>ntpdc</tt> program
and the <tt>monlist</tt> command or further information. The
default for this flag is <tt>enable</tt>.</dd>
<dt><tt>ntp</tt></dt>
<dd>Enables the server to adjust its local clock by means of NTP.
If disabled, the local clock free-runs at its intrinsic time and
frequency offset. This flag is useful in case the local clock is
controlled by some other device or protocol and NTP is used only to
provide synchronization to other clients. In this case, the local
clock driver can be used to provide this function and also certain
time variables for error estimates and leap-indicators. See the <a
href="refclock.htm">Reference Clock Drivers</a> page for further
information. The default for this flag is <tt>enable</tt>.</dd>
<dt><tt>stats</tt></dt>
<dd>Enables the statistics facility. See the <a href="monopt.htm">
Monitoring Options</a> page for further information. The default
for this flag is <tt>enable</tt>.</dd>
</dl>
</dd>
<dt><tt>logconfig <i>configkeyword</i></tt></dt>
<dd>This command controls the amount and type of output written to
the system <tt>syslog</tt> facility or the alternate <tt>
logfile</tt> log file. By default, all output is turned on. All <i>
<tt>configkeyword</tt></i> keywords can be prefixed with <tt>
=</tt>, <tt>+</tt> and <tt>-</tt>, where <tt>=</tt> sets the <tt>
syslogmask</tt>, <tt>+</tt> adds and <tt>-</tt> removes messages.
<tt>syslog messages</tt> can be controlled in four classes
(<tt>clock</tt>, <tt>peer</tt>, <tt>sys</tt> and <tt>sync</tt>).
Within these classes four types of messages can be controlled.</dd>
<dd>Informational messages (<tt>info</tt>) control configuration
information. Event messages (<tt>events</tt>) control logging of
events (reachability, synchronization, alarm conditions).
Statistical output is controlled with the <tt>statistics</tt>
keyword. The final message group is the status messages. This
describes mainly the synchronizations status. Configuration
keywords are formed by concatenating the message class with the
event class. The <tt>all</tt> prefix can be used instead of a
message class. A message class may also be followed by the <tt>
all</tt> keyword to enable/disable all messages of the respective
message class.</dd>
<dd>Thus, a minimal log configuration could look like this:
<p><tt>logconfig=syncstatus +sysevents</tt></p>
<p>This would just list the synchronizations state of <tt>ntpd</tt>
and the major system events. For a simple reference server, the
following minimum message configuration could be useful:</p>
<p><tt>logconfig=syncall +clockall</tt></p>
<p>This configuration will list all clock information and
synchronization information. All other events and messages about
peers, system events and so on is suppressed.</p>
</dd>
<dt><tt>logfile <i>logfile</i></tt></dt>
<dd>This command specifies the location of an alternate log file to
be used instead of the default system <tt>syslog</tt>
facility.</dd>
<dt><tt>setvar <i>variable</i> [default]</tt></dt>
<dd>This command adds an additional system variable. These
variables can be used to distribute additional information such as
the access policy. If the variable of the form <tt><i>name</i> =
<i>value</i></tt> is followed by the <tt>default</tt> keyword, the
variable will be listed as part of the default system variables
(<tt>ntpq rv</tt> command). These additional variables serve
informational purposes only. They are not related to the protocol
other that they can be listed. The known protocol variables will
always override any variables defined via the <tt>setvar</tt>
mechanism. There are three special variables that contain the names
of all variable of the same group. The <tt>sys_var_list</tt> holds
the names of all system variables. The <tt>peer_var_list</tt> holds
the names of all peer variables and the <tt>clock_var_list</tt>
holds the names of the reference clock variables.</dd>
<dt><tt>tinker [ step <i>step</i> | panic <i>panic</i> | dispersion
<i>dispersion</i> | stepout <i>stepout</i> | minpoll <i>minpoll</i>
]</tt></dt>
<dd>This command can be used to alter several system variables in
very exceptional circumstances. It should occur in the
configuration file before any other configuration options. The
default values of these variables have been carefully optimized for
a wide range of network speeds and reliability expectations. In
general, they interact in intricate ways that are hard to predict
and some combinations can result in some very nasty behavior. Very
rarely is it necessary to change the default values; but, some
folks can't resist twisting the knobs anyway and this command is
for them. Emphasis added: twisters are on their own and can expect
no help from the support group.
<p>All arguments are in floating point seconds or seconds per
second. The <tt>minpoll</tt> argument is an integer in seconds to
the power of two. The variables operate as follows:</p>
</dd>
<dd>
<dl>
<dt><tt>step <i>step</i></tt></dt>
<dd>The argument becomes the new value for the step threshold,
normally 0.128 s. If set to zero, step adjustments will never
occur. In general, if the intent is only to avoid step adjustments,
the step threshold should be left alone and the <tt>-x</tt> command
line option be used instead.</dd>
<dt><tt>panic <i>panic</i></tt></dt>
<dd>The argument becomes the new value for the panic threshold,
normally 1000 s. If set to zero, the panic sanity check is disabled
and a clock offset of any value will be accepted.</dd>
<dt><tt>dispersion <i>dispersion</i></tt></dt>
<dd>The argument becomes the new value for the dispersion increase
rate, normally .000015.</dd>
<dt><tt>stepout <i>stepout</i></tt></dt>
<dd>The argument becomes the new value for the watchdog timeout,
normally 900 s.</dd>
<dt><tt>minpoll <i>minpoll</i></tt></dt>
<dd>The argument becomes the new value for the minimum poll
interval used when configuring multicast client, manycast client
and , symmetric passive mode association. The value defaults to 6
(64 s) and has a lower limit of 4 (16 s).</dd>
<dt><tt>allan <i>allan</i></tt></dt>
<dd>The argument becomes the new value for the minimum Allan
intercept, which is a parameter of the PLL/FLL clock discipline
algorithm. The value defaults to 1024 s, which is also the lower
limit.</dd>
<dt><tt>huffpuff <i>huffpuff</i></tt></dt>
<dd>The argument becomes the new value for the experimental
huff-n'-puff filter span, which determines the most recent interval
the algorithm will search for a minimum delay. The lower limit is
900 s (15 m), but a more reasonable value is 7200 (2 hours). There
is no default, since the filter is not enabled unless this command
is given.</dd>
</dl>
</dd>
<dt><tt>trap <i>host_address</i> [port <i>port_number</i>]
[interface <i>interface_address</i>]</tt></dt>
<dd>This command configures a trap receiver at the given host
address and port number for sending messages with the specified
local interface address. If the port number is unspecified, a value
of 18447 is used. If the interface address is not specified, the
message is sent with a source address of the local interface the
message is sent through. Note that on a multihomed host the
interface used may vary from time to time with routing changes.
<p>The trap receiver will generally log event messages and other
information from the server in a log file. While such monitor
programs may also request their own trap dynamically, configuring a
trap receiver will ensure that no messages are lost when the server
is started.</p>
</dd>
</dl>
<h4>Files</h4>
<tt>ntp.drift</tt> frequency compensation (PPM)
<hr>
<a href="index.htm"><img align="left" src="pic/home.gif" alt=
"gif"></a>
<address><a href="mailto:mills@udel.edu">David L. Mills
&lt;mills@udel.edu&gt;</a></address>
</body>
</html>