NetBSD/usr.sbin/xntp/html/ntpdate.html

146 lines
6.3 KiB
HTML

<!-- $NetBSD: ntpdate.html,v 1.1 1998/12/30 20:20:36 mcr Exp $ -->
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML Strict//EN">
<html><head><title>
ntpdate - set the date and time via NTP
</title></head><body><h3>
<code>ntpdate</code> - set the date and time via NTP
</h3><hr>
<p><h4>Synopsis</h4>
<p><code>ntpdate [ -bBdoqsuv ] [ -a <i>key</i> ] [ -e <i>authdelay</i> ] [
-k <i>keyfile</i> ] [ -o <i>version</i> ] [ -p <i>samples</i> ] [ -t
<i>timeout</i> ] <i>server</i> [ ... ]</code>
<p><h4>Description</h4>
<p><code>ntpdate</code> sets the local date and time by polling the
Network Time Protocol (NTP) server(s) given as the <i>server</i>
arguments to determine the correct time. It must be run as root on the
local host. A number of samples are obtained from each of the servers
specified and a subset of the NTP clock filter and selection algorithms
are applied to select the best of these. Note that the accuracy and
reliability of <code>ntpdate</code> depends on the number of servers,
the number of polls each time it is run and the interval between runs.
<p><code>ntpdate</code> can be run manually as necessary to set the host
clock, or it can be run from the host startup script to set the clock at
boot time. This is useful in some cases to set the clock initially
before starting the NTP daemon <code>xntpd</code>. It is also possible
to run <code>ntpdate</code> from a <code>cron</code> script. However, it
is important to note that <code>ntpdate</code> with contrived
<code>cron</code> scripts is no substitute for the NTP daemon, which
uses sophisticated algorithms to maximize accuracy and reliability while
minimizing resource use. Finally, since <code>ntpdate</code> does not
discipline the host clock frequency as does <code>xntpd</code>, the
accuracy using <code>ntpdate</code> is limited.
<p>Time adjustments are made by <code>ntpdate</code> in one of two ways.
If <code>ntpdate</code> determines the clock is in error more than 0.5
second it will simply step the time by calling the system
<code>settimeofday()</code> routine. If the error is less than 0.5
seconds, it will slew the time by calling the system
<code>adjtime()</code> routine. The latter technique is less disruptive
and more accurate when the error is small, and works quite well when
<code>ntpdate</code> is run by <code>cron</code> every hour or two.
<p><code>ntpdate</code> will decline to set the date if an NTP server
daemon (e.g., <code>xntpd</code>) is running on the same host. When
running <code>ntpdate</code> on a regular basis from <code>cron</code>
as an alternative to running a daemon, doing so once every hour or two
will result in precise enough timekeeping to avoid stepping the clock.
<p><h4>Command Line Options</h4>
<dl>
<dt><code>-a <i>key</i></code>
<dd>Enable the authentication function and specify the key identifier to
be used for authentication as the argument
<i>key</i><code>ntpdate</code>. The keys and key identifiers must match
in both the client and server key files. The default is to disable the
authentication function.
<p><dt><code>-B</code>
<dd>Force the time to always be slewed using the adjtime() system call,
even if the measured offset is greater than +-128 ms. The default is to
step the time using settimeofday() if the offset is greater than +-128
ms. Note that, if the offset is much greater than +-128 ms in this case,
that it can take a long time (hours) to slew the clock to the correct
value. During this time. the host should not be used to synchronize
clients.
<p><dt><code>-b</code>
<dd>Force the time to be stepped using the settimeofday() system call,
rather than slewed (default) using the adjtime() system call. This
option should be used when called from a startup file at boot time.
<p><dt><code>-d</code>
<dd>Enable the debugging mode, in which <code>ntpdate</code> will go
through all the steps, but not adjust the local clock. Information
useful for general debugging will also be printed.
<p><dt><code>-e <i>authdelay</i></code>
<dd>Specify the processing delay to perform an authentication function
as the value <i>authdelay</i>, in seconds and fraction (see
<code>xntpd</code> for details). This number is usually small enough to
be negligible for most purposes, though specifying a value may improve
timekeeping on very slow CPU's.
<p><dt><code>-k <i>keyfile</i></code>
<dd>Specify the path for the authentication key file as the string
<i>keyfile</i>. The default is <code>/etc/ntp.keys</code>. This file
should be in the format described in <code>xntpd</code>.
<p><dt><code>-o <i>version</i></code>
<dd>Specify the NTP version for outgoint packets as the integer
<i>version</i>, which can be 1 or 2. The default is 3. This allows
<code>ntpdate</code> to be used with older NTP versions.
<p><dt><code>-p <i>samples</i></code>
<dd>Specify the number of samples to be acquired from each server as the
integer <i>samples</i>, with values from 1 to 8 inclusive. The default
is 4.
<p><dt><code><i>-q</i></code>
<dd>Query only - don't set the clock.
<p><dt><code>-s</code>
<dd>Divert logging output from the standard output (default) to the
system <code>syslog</code> facility. This is designed primarily for
convenience of <code>cron</code> scripts.
<p><dt><code>-t <i>timeout</i></code>
<dd>Specify the maximum time waiting for a server response as the value
<i>timeout</i>, in seconds and fraction. The value is is rounded to a
multiple of 0.2 seconds. The default is 1 second, a value suitable for
polling across a LAN.
<p><dt><code>-u</code>
<dd>Direct <code>ntpdate</code> to use an unprivileged port or outgoing
packets. This is most useful when behind a firewall that blocks incoming
traffic to privileged ports, and you want to synchronise with hosts
beyond the firewall. Note that the <code>-d</code> option always uses
unprivileged ports.
<p><dt><code>-<i>v</i></code>
<dd>Be verbose. This option will cause <code>ntpdate</code>'s version
identification string to be logged.
</dl>
<p><h4>Files</h4>
<p><code>/etc/ntp.keys</code> - encryption keys used by
<code>ntpdate</code>.
<p><h4>Bugs</h4>
<p>The slew adjustment is actually 50% larger than the measured offset,
since this (it is argued) will tend to keep a badly drifting clock more
accurate. This is probably not a good idea and may cause a troubling
hunt for some values of the kernel variables <code>tick</code> and
<code>tickadj</code>.
<hr><address>David L. Mills (mills@udel.edu)</address></body></html>