xntpd(1M)
NAME
xntpd - Network Time Protocol daemon
SYNOPSIS
/usr/lib/inet/xntpd [-aAbdm] [-c conffile] [-e authdelay]
[-f driftfile] [-k keyfile] [-l logfile] [-p pidfile] [-r
broadcastdelay] [-s statsdir] [-t trustedkey] [-v variable]
[-V variable]
DESCRIPTION
xntpd is a daemon which sets and maintains a UNIX system
time-of-day in agreement with Internet standard time
servers. xntpd is a complete implementation of the Network
Time Protocol (NTP) version 3 standard, as defined by RFC
1305. It also retains compatibility with version 1 and 2
servers as defined by RFC 1059 and RFC 1119, respectively.
The computations done in the protocol and clock adjustment
code are carried out with high precision and with attention
to the details which might introduce systematic bias into
the computations. This is done to try to maintain an accu-
racy suitable for synchronizing with even the most precise
external time source.
Ordinarily, xntpd reads its configuration from a configura-
tion file at startup time. The default configuration file
name is /etc/inet/ntp.conf, although this may be overridden
from the command line. It is also possible to specify a
working, although limited, xntpd configuration entirely on
the command line, obviating the need for a configuration
file. This may be particularly appropriate when xntpd is to
be configured as a broadcast or multicast client, with all
peers being determined by listening to broadcasts at run
time. Through the use of the ntpq(1M) program, various
internal xntpd variables can be displayed and configuration
options altered while the daemon is running.
The daemon can operate in any of several modes, including
symmetric active/passive, client/server and
broadcast/multicast. A broadcast/multicast client can
automatically discover remote servers, compute one-way delay
correction factors and configure itself automatically. This
makes it possible to deploy a fleet of workstations without
specifying a configuration file or configuration details
specific to its environment.
OPTIONS
The following command line arguments are understood by
xntpd. See Configuration Commands for a more complete func-
tional description:
-a Run in authentication mode.
-A Disable authentication mode.
-b Listen for broadcast NTP and sync to this if avail-
able.
-c conffile
Specify an alternate configuration file.
-d Specify debugging mode. This flag may occur multiple
times, with each occurrence indicating greater detail
of display.
-e authdelay
Specify the time (in seconds) it takes to compute the
NTP encryption field on this computer.
-f driftfile
Specify the location of the drift file.
-k keyfile
Specify the location of the file which contains the
NTP authentication keys.
-l logfile
Specify a log file instead of logging to syslog.
-m Listen for multicast messages and synchronize to them
if available (requires multicast kernel).
-p pidfile
Specify the name of the file to record the daemon's
process id.
-r broadcast
Ordinarily, the daemon automatically compensates for
the network delay between the broadcast/multicast
server and the client; if the calibration procedure
fails, use the specified default delay (in seconds).
-s statsdir
Specify the directory to be used for creating statis-
tics files.
-t trustedkey
Add a key number to the trusted key list.
-v variable
Add a system variable.
-V variable
Add a system variable listed by default.
USAGE
xntpd's configuration file format is similar to other Unix
configuration files. Comments begin with a `#' character and
extend to the end of the line. Blank lines are ignored. Con-
figuration commands consist of an initial keyword followed
by a list of arguments, separated by whitespace. Some argu-
ments may be optional. These commands may not be continued
over multiple lines. Arguments may be host names, host
addresses written in dotted-decimal, integers, floating
point numbers (when specifying times in seconds) and text
strings.
Configuration Commands
In the following descriptions, optional arguments are delim-
ited by `[]', while alternatives are separated by `|'. The
first three commands specify various time servers to be used
and time services to be provided.
peer host_address [ key # ] [ version # ][ prefer ]
Specifies that the local server is to operate in "sym-
metric active" mode with the remote server
host_address named in the command. In this mode, the
local server can be synchronized to the remote server.
In addition, the remote server can be synchronized by
the local server. This is useful in a network of
servers where, depending on various failure scenarios,
either the local or remote server host may be the
better source of time. The peer command, and the
server and broadcast commands that follow, can take
the following arguments:
key Indicates that all packets sent to the address
are to include authentication fields, encrypted
using the specified key number. The range of
this number is that of an unsigned 32 bit
integer. By default, an encryption field is not
included.
version
Specifies the version number to be used for out-
going NTP packets. Versions 1, 2, and 3 are the
choices; version 3 is the default.
prefer
Marks the host as a preferred host. This host
will be preferred for synchronization over other
comparable hosts.
server host_address [ key # ] [ version f1# ]
[ prefer ] [ mode f1# ] server
Specifies that the local server is to operate in
"client" mode with the remote server named in the com-
mand. In this mode the local server can be synchron-
ized to the remote server, but the remote server can
never be synchronized to the local server.
broadcast host_address [ key # ] [ version # ] [ ttl # ]
Specifies that the local server is to operate in
"broadcast" mode where the local server sends periodic
broadcast messages to a client population at the
broadcast/multicast address named in the command.
Ordinarily, this specification applies only to the
local server operating as a transmitter. For operation
as a broadcast client, see broadcastclient or multi-
castclient commands elsewhere in this document. In
broadcast mode the host_address is usually the broad-
cast address on a local network or a multicast address
assigned to NTP. The IANA has assigned the network,
224.0.1.1 to NTP. This is presently the only network
that should be used. The following option is used only
with the broadcast mode:
ttl Specifies the time-to-live (TTL) to use on mul-
ticast packets. Selection of the proper value,
which defaults to 127, is something of a black
art and must be coordinated with the network
administrator(s).
broadcastclient
Directs the local server to listen for broadcast mes-
sages on the local network, in order to discover other
servers on the same subnet. Upon hearing a broadcast
message for the first time, the local server measures
the nominal network delay using a brief client/server
exchange with the remote server. Then the server
enters the "broadcastclient" mode, in which it listens
for and synchronizes to succeeding broadcast messages.
In order to avoid accidental or malicious disruption
in this mode, both the local and remote servers must
operate using authentication, with the same trusted
key and key identifier.
multicastclient
[ IP address ... ] Used in the same way as the broad-
castclient command, but operates using IP multicast-
ing. Support for this command requires the use of
authentication. If one or more IP addresses are given,
the server joins the respective multicast group(s). If
none are given, the IP address assigned to NTP
(224.0.1.1) is assumed.
driftfile filename
Specifies the name of the file used to record the fre-
quency offset of the local clock oscillator. If the
file exists, it is read at startup in order to set the
initial frequency offset. Then the file is updated
once per hour with the current offset computed by the
daemon. If the file does not exist or this command is
not given, the initial frequency offset is assumed to
be zero. In this case, it may take some hours for the
frequency to stabilize and the residual timing errors
to subside. The file contains a single floating point
value equal to the offset in parts-per-million (ppm).
The file is updated by first writing the current drift
value into a temporary file and then using rename(2)
to replace the old version. This implies that xntpd
must have write permission for the directory the drift
file is located in, and that file system links, sym-
bolic or otherwise, should probably be avoided.
enable auth|bclient|pll|monitor|stats [ ... ]
disable auth|bclient|pll|monitor|stats
[ ... ]
Provides a way to enable or disable various server
options. To do so, execute a two word command, where
the first word is enable or disable and the second is
the flag. Flags not mentioned are unaffected. Flags
that can be changed are described below, along with
their default values.
Flag Default Description
auth disable Causes the server to synchronize
with unconfigured peers only if
the peer has been correctly
authenticated using a trusted key
and key identifier.
bclient disable Causes the server to listen for a
message from a broadcast or mul-
ticast server. After this occurs,
an association is automatically
instantiated for that server.
default for this flag is disable
(off).
pll enable Enables the server to adjust its
local clock. If not set, the
local clock free-runs at its
intrinsic time and frequency
offset. This flag is useful in
case the local clock is con-
trolled by some other device or
protocol and NTP is used only to
provide synchronization to other
clients.
monitor disable Enables the monitoring facility
(see elsewhere).
stats enable Enables statistics facility
filegen (see Monitoring Commands
below).
slewalways [ yes|no ]
Force xntpd to always slew the time.
Authentication Commands
keys filename
Specifies the name of a file which contains the
encryption keys and key identifiers used by xntpd when
operating in authenticated mode. The format of this
file is described later in this document.
trustedkey
# [ # ... ] Specifies the encryption key identifiers
which are trusted for the purposes of authenticating
peers suitable for synchronization. The authentica-
tion procedures require that both the local and remote
servers share the same key and key identifier, defined
to be used for this purpose. However, different keys
can be used with different servers. The arguments are
32 bit unsigned integers. Note, however, that key 0 is
fixed and globally known. If meaningful authentication
is to be performed, the 0 key should not be trusted.
controlkey #
Specifies the key identifier to use with the ntpq(1M)
program, which is useful to diagnose and repair prob-
lems that affect xntpd operation. The operation of the
ntpq program and xntpd conform to those specified in
RFC 1305. Requests from a remote ntpq program which
affect the state of the local server must be authenti-
cated. This requires that both the remote program and
local server share a common key and key identifier.
The argument to this command is a 32 bit unsigned
integer. If no controlkey command is included in the
configuration file, or if the keys don't match. These
requests are ignored.
Access Control Commands
restrictaddress [ mask numeric_mask ] [ flag ] [ ... ]
xntpd implements a general purpose address-and-mask
based restriction list. The list is sorted by IP
address and mask, and the list is searched in this
order for matches, with the last match found defining
the restriction flags associated with the incoming
packets. The source address of incoming packets is
used for the match, with the 32 bit address being log-
ically and'ed with the mask associated with the res-
triction entry and then compared with the entry's
address (which has also been and'ed with the mask) to
look for a match. The "mask" argument defaults to
255.255.255.255, meaning that the "address" is treated
as the address of an individual host. A default entry
(address 0.0.0.0, mask 0.0.0.0) is always included
and, given the sort algorithm, is always the first
entry in the list. Note that, while "address" is nor-
mally given in dotted-quad format, the text string
"default", with no mask option, may be used to indi-
cate the default entry.
In the current implementation, flags always restrict
access, i.e., an entry with no flags indicates that
free access to the server is to be given. The flags
are not orthogonal, in that more restrictive flags
often make less restrictive ones redundant. The flags
can generally be classed into two categories, those
which restrict time service and those which restrict
informational queries and attempts to do run time
reconfiguration of the server.
One or more of the following flags may be specified:
ignore
Ignore all packets from hosts which match this
entry. If this flag is specified neither queries
nor time server polls will be responded to.
noquery
Ignore all NTP mode 7 packets (i.e., information
queries and configuration requests) from the
source. Time service is not affected.
nomodify
Ignore all NTP mode 7 packets which attempt to
modify the state of the server (i.e., run time
reconfiguration). Queries which return informa-
tion are permitted.
notrap
Decline to provide mode 6 control message trap
service to matching hosts. The trap service is a
subsystem of the mode 6 control message protocol
which is intended for use by remote event log-
ging programs.
lowpriotrap
Declare traps set by matching hosts to be low
priority. The number of traps a server can main-
tain is limited. The current limit is 3. Traps
are usually assigned on a first come, first
served basis, with later trap requestors being
denied service. This flag modifies the assign-
ment algorithm by allowing low priority traps to
be overridden by later requests for normal
priority traps.
noserve
Ignore NTP packets whose mode is other than 7.
In effect, time service is denied, though
queries may still be permitted.
nopeer
Provide stateless time service to polling hosts,
but do not allocate peer memory resources to
these hosts even if they otherwise might be con-
sidered useful as future synchronization
partners.
notrust
Treat these hosts normally in other respects,
but never use them as synchronization sources.
limited
These hosts are subject to a limitation on
number of clients from the same net that will be
accepted. Net in this context refers to the IP
notion of net (class A, class B, class C, etc.).
Only the first client_limit hosts that have
shown up at the server and that have been active
during the last client_limit_period seconds are
accepted. Requests from other clients from the
same net are rejected. Only time request packets
are taken into account. "Private", "control",
and "broadcast" packets are not subject to
client limitation and therefore do not contri-
bute to client count. A history of clients is
kept using the monitoring capability of xntpd.
Thus, monitoring is active as long as there is a
restriction entry with the limited flag. The
default value for client_limit is 3. The default
value for client_limit_period is 3600 seconds.
Currently both variables are not runtime
configurable.
ntpport
This is actually a match algorithm modifier,
rather than a restriction flag. Its presence
causes the restriction entry to be matched only
if the source port in the packet is the standard
NTP UDP port (123). Both ntpport and non-ntpport
may be specified. The ntpport is considered more
specific and is sorted later in the list.
Default restriction list entries, with the
flags, ignore, ntpport, for each of the local
host's interface addresses are inserted into the
table at startup to prevent the server from
attempting to synchronize to its own time. A
default entry is also always present, though if
it is otherwise unconfigured no flags are asso-
ciated with the default entry (i.e., everything
besides your own NTP server is unrestricted).
The restriction facility was added to allow the
current access policies of the time servers run-
ning on the NSF net backbone to be implemented
with xntpd as well. This facility may be useful
for keeping unwanted or broken remote time
servers from affecting your own. However, it
should not be considered an alternative to the
standard NTP authentication facility.
clientlimit limit
Sets client_limit to limit; allows configuration
of client limitation policy. This variable
defines the number of clients from the same net-
work that are allowed to use the server.
clientperiod period
Sets client_limit_period; allows configuration
of client limitation policy. This variable
specifies the number of seconds after which a
client is considered inactive and thus no longer
is counted for client limit restriction.
Monitoring Commands
statsdir /directory path/
Indicates the full path of a directory where statis-
tics files should be created (see below). This keyword
allows the (otherwise constant) filegen filename pre-
fix to be modified for file generation sets used for
handling statistics logs (see filegen statement
below).
statistics name ...
Enables writing of statistics records. Currently,
three kinds of statistics are supported. Each type is
described below by giving its name, a sample line of
data, and an explanation of each field:
loopstats
enables recording of loop filter statistics
information. Each update of the local clock out-
puts a line of the following form to the file
generation set named "loopstats":
48773 10847.650 0.0001307 17.3478 2
Field No.
Description
1 The date (Modified Julian day)
2 The time (seconds and fraction past UTC mid-
night)
3 Time offset in seconds
4 Frequency offset in parts-per-million
5 Time constant of the clock-discipline algorithm
at each update of the clock
peerstats
enables recording of peer statistics informa-
tion. This includes statistics records of all
peers of a NTP server and of the 1-pps signal,
where present and configured. Each valid update
appends a line similar to the one below, to the
current element of a file generation set named
"peerstats":
48773 10847.650 127.127.4.1 9714 -0.001605 \
0.00000 0.00142
Field No.
Description
1 The date (Modified Julian Day)
2 The time (seconds and fraction past UTC
midnight)
3 The peer address in dotted-quad notation
4 peer status. The status field is encoded in hex
in the format described in Appendix B.2.2 of the
NTP specification, RFC 1305.
5 Offset in seconds
6 Delay in seconds
7 Dispersion in seconds
clockstats
enables recording of clock driver statistics
information. Each update received from a clock
driver outputs a line of the following form to
the file generation set named "clockstats":
49213 525.624 127.127.4.1 93 226 \
00:08:29.606 D
Field No.
Description
1 The date (Modified Julian Day)
2 The time (seconds and fraction past UTC mid-
night)
3 The clock address in dotted-quad notation
4 The last timecode received from the clock in
decoded ASCII format, where meaningful
In some clock drivers a good deal of additional
information can be gathered and displayed as
well.
Statistic files are managed using file genera-
tion sets (see filegen below). The information
obtained by enabling statistics recording allows
analysis of temporal properties of a xntpd
server. It is usually only useful to primary
servers or maybe main campus servers.
filegen name [ file filename ] [ type typename ][ flag flagval ]
[ link|nolink ] [ enable|disable ]
Configures setting of generation file set name. Gen-
eration file sets provide a means for handling files
that are continuously growing during the lifetime of a
server. Server statistics are a typical example for
such files. Generation file sets provide access to a
set of files used to store the actual data. At any
time at most one element of the set is being written
to. The type given specifies when and how data will be
directed to a new element of the set. This way, infor-
mation stored in elements of a file set that are
currently unused are available for administrational
operations without the risk of disturbing the opera-
tion of xntpd. (Most important: they can be removed to
free space for new data produced.)
Filenames of set members are built from three ele-
ments:
prefix
This is a constant filename path. It is not subject to
modifications via the filegen statement. It is defined
by the server, usually specified as a compile time
constant. It may, however, be configurable for indivi-
dual file generation sets via other commands. For
example, the prefix used with "loopstats" and "peer-
stats" filegens can be configured using the statsdir
statement explained above.
filename
This string is directly concatenated to the prefix
mentioned above (no intervening `/' (slash)). This can
be modified using the file argument to the filegen
statement. No `..' elements are allowed in this com-
ponent to prevent filenames referring to parts outside
the filesystem hierarchy denoted by prefix.
suffix
This part is reflects individual elements of a file
set. It is generated according to the type of a file
set as explained below.
A file generation set is characterized by its type. The fol-
lowing types are supported:
none The file set is actually a single plain file.
pid One element of file set is used per incarnation of a
xntpd server. This type does not perform any changes
to file set members during runtime. However it pro-
vides an easy way of separating files belonging to
different xntpd server incarnations. The set member
filename is built by appending a `.' (dot) to con-
catenated prefix and filename strings, and appending
the decimal representation of the process id of the
xntpd server process.
day One file generation set element is created per day.
The term day is based on UTC . A day is defined as the
period between 00:00 and 24:00 UTC . The file set
member suffix consists of a `.' (dot) and a day
specification in the form, YYYYMMDD. YYYY is a 4 digit
year number (e.g., 1992). MM is a two digit month
number. DD is a two digit day number. Thus, all infor-
mation written at December 10th, 1992 would end up in
a file named, PrefixFilename.19921210.
week Any file set member contains data related to a certain
week of a year. The term week is defined by computing
"day of year" modulo 7. Elements of such a file gen-
eration set are distinguished by appending the follow-
ing suffix to the file set filename base: a dot, a
four digit year number, the letter `W', and a two
digit week number. For example, information from Janu-
ary, 5th 1992 would end up in a file with suffix
".1992W1".
month One generation file set element is generated per
month. The file name suffix consists of a dot, a four
digit year number, and a two digit month.
year One generation file elment is generated per year. The
filename suffix consists of a dot and a 4 digit year
number.
age This type of file generation sets changes to a new
element of the file set every 24 hours of server
operation. The filename suffix consists of a dot, the
letter `a', and an eight digit number. This number is
taken to be the number of seconds the server is run-
ning at the start of the corresponding 24 hour period.
Information is only written to a file generation set when
this set is enabled. Output is prevented by specifying, dis-
abled.
It is convenient to be able to access the current element of
a file generation set by a fixed name. This feature is
enabled by specifying link and disabled using nolink. If
link is specified, a hard link from the current file set
element to a file without suffix is created. When there is
already a file with this name and the number of links of
this file is one, it is renamed appending a dot, the letter,
`C', and the pid of the xntpd server process. When the
number of links is greater than one, the file is unlinked.
This allows the current file to be accessed by a constant
name.
Miscellaneous Commands
broadcastdelay seconds
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 local and remote servers. In some cases,
the calibration procedure may fail due to, for exam-
ple, network or server access controls. This command
specifies the default delay to be used under these
circumstances. Typically (for Ethernet), a number
between 0.003 and 0.007 is appropriate for seconds.
When this command is not used, the default is 0.004
seconds.
trap host_address [ port port_number ]
[ interface interface_address ]
Configures a trap receiver at the given host_address
and port_number for sending messages with the speci-
fied local interface_address. If the port number is
unspecified, a value of 18447 is used. If the inter-
face address is not specified, the message is sent
with the source address of the local interface the
message is sent through. On a multi-homed host, the
interface used may change with routing changes.
C information from the server in a log file. While
such monitor programs may also request their own trap
dynamically, configuring a trap receiver ensures that
no messages are lost when the server is started.
setvar variable [ default ]
This command adds an additional system variable. Vari-
ables like this can be used to distribute additional
information such as the access policy. If the variable
of the form, variable_name=value is followed by the
default keyword, the variable will be listed as one of
the default system variables (see the ntpq(1M) com-
mand). Additional variables serve informational pur-
poses only. They can be listed; but they are not
related to the protocol. The known protocol variables
always override any variables defined via the setvar
mechanism.
Three special variables contain the names of all vari-
able of the same group. sys_var_list holds the names
of all system variables. peer_var_list holds the names
of all peer variables. And clock_var_list hold the
names of the reference clock variables.
monitor [ yes|no ]
authenticate [ yes|no ]
These commands have been superseded by the enable and
disable commands. They are listed here for historical
purposes.
logconfig configkeyword
Controls the amount of output written to syslog or the
logfile. By default all output is turned on. config-
keyword is formed by concatenating the message class
with the event class. It is permissible to use the
prefix, all, instead of a message class. A message
class may also be followed by the keyword, all, mean-
ing to enable/disable all of the respective message
class. All configkeywords can be prefixed with the
symbols, `=', `+' and `-' . Here, `=' sets the syslog-
mask, `+' adds messages, and `-' removes messages.
Syslog messages can be controlled in four classes:
sys, peer, clock, sync. Within these classes four
types of messages can be controlled. Each is described
below, along with its configkeyword:
Configkeyword
Message type
info Informational messages control configuration informa-
tion.
events
Event messages control logging of events (reachabil-
ity, synchronization, alarm conditions).
statistics
Statistical messages control statistical output.
status
Status messages describe mainly the synchronization
status.
A minimal log configuration might look like this:
logconfig =syncstatus +sysevents
A configuration like this lists, just the synchronization
state of xntp and the major system events. For a simple
reference server, the following minimum message configura-
tion could be useful:
logconfig =syncall +clockall
This configuration lists all clock information and synchron-
ization information. All other events and messages about
peers, system events and so on, is suppressed.
Authentication Key File Format
The NTP standard specifies an extension to allow verifica-
tion of the authenticity of received NTP packets, and to
provide an indication of authenticity in outgoing packets.
This is implemented in xntpd using the DES or MD5 algorithms
to compute a digital signature, or message-digest. The
specification allows any one of possibly 4 billion keys,
numbered with 32 bit key identifiers, to be used to authen-
ticate an association. The servers involved in an associa-
tion must agree on the key and key identifier used to
authenticate their data. However they must each learn the
key and key identifier independently. In the case of DES,
the keys are 56 bits long with, depending on type, a parity
check on each byte. In the case of MD5, the keys are 64 bits
(8 bytes). xntpd reads its keys from a file specified using
the -k command line option or the keys statement in the con-
figuration file. While key number 0 is fixed by the NTP
standard (as 56 zero bits) and may not be changed, one or
more of the keys numbered 1 through 15 may be arbitrarily
set in the keys file.
The key file uses the same comment conventions as the confi-
guration file. Key entries use a fixed format of the form,
keyno type key. Here, keyno is a positive integer, type is a
single character which defines the format the key is given
in, and key is the key itself.
The key may be given in one of several different formats,
controlled by the type character. The different key types,
and corresponding formats, are described below:
Key: S
Format:
A 64 bit hexadecimal number in DES format
In this format, the high order 7 bits of each octet
are used to form the 56 bit key while the low order
bit of each octet is given a value such that odd par-
ity is maintained for the octet. Leading zeroes must
be specified (i.e., the key must be exactly 16 hex
digits long) and odd parity must be maintained. Hence
a zero key, in standard format, would be given as:
0101010101010101.
Key: N
Format:
A 64 bit hexadecimal number in NTP format
This format is the same as the DES format except the
bits in each octet have been rotated one bit right so
that the parity bit is now the high order bit of the
octet. Leading zeroes must be specified and odd parity
must be maintained. A zero key in NTP format would be
specified as: 8080808080808080.
Key: A
Format:
A 1-to-8 character ASCII string
A key is formed from this by using the lower order 7
bits of the ASCII representation of each character in
the string. Zeroes are added on the right when neces-
sary to form a full width 56 bit key.
Key: M
Format:
A 1-to-8 character ASCII string, using the MD5 authen-
tication scheme.
Note that both the keys and the authentication schemes
(DES or MD5) must be identical between a set of peers
sharing the same key number.
Primary Clock Support
xntpd has been built to be compatible with all supported
types of reference clocks. A reference clock is generally
(though not always) a radio timecode receiver which is syn-
chronized to a source of standard time such as the services
offered by the NRC in Canada and NIST in the U.S. The inter-
face between the computer and the timecode receiver is dev-
ice dependent and will vary, but it is often a serial port.
For the purposes of configuration, xntpd treats reference
clocks in a manner analogous to normal NTP peers as much as
possible. Reference clocks are referred to by address, much
as a normal peer is. However, an invalid IP address is used
to distinguish them from normal peers. Reference clock
addresses are of the form 127.127.t.u where t is an integer
denoting the clock type and u indicates the type-specific
unit number. Reference clocks are configured using a server
statement in the configuration file where the host_address
is the clock address. The key, version and ttl options are
not used for reference clock support. Some reference clocks
require a mode option to further specify their operation.
The prefer option can be useful to persuade the server to
cherish a reference clock with somewhat more enthusiasm than
other reference clocks or peers. Clock addresses may gen-
erally be used anywhere in the configuration file that a
normal IP address can be used. For example, they can be used
in restrict statements, although such use would normally be
considered strange.
Reference clock support provides the fudge command, which
can be used to configure reference clocks in special ways.
The generic format that applies to this command is,
fudge 127.127.t.u [ time1 secs ] [ time2 secs ]\
[ stratum int ] [ refid int ] \
[ flag1 0|1 ] [ flag2 0|1 ] [ flag3 0|1 ] [ flag4 0|1 ]
with options described as follows:
time1
time2 Are specified in fixed point seconds and used in some
clock drivers as calibration constants. By convention,
and unless indicated otherwise, time1 is used as a
calibration constant to adjust the nominal time offset
of a particular clock to agree with an external stan-
dard, such as a precision PPS signal. The specified
offset is in addition to the propagation delay pro-
vided by other means, such as internal DIP switches.
stratum
Is a number in the range zero to 15 and is used to
assign a nonstandard operating stratum to the clock.
refid Is an ASCII string in the range one to four characters
and is used to assign a nonstandard reference identif-
ier to the clock.
flag1
flag2
flag3
flag4 Are binary flags used for customizing the clock
driver. The interpretation of these values, and
whether they are used at all, is a function of the
needs of the particular clock driver. However, by con-
vention, and unless indicated otherwise, flag3 invokes
the TIOCSPPS ioctl, while flag4 is used to enable
recording verbose monitoring data to the clockstats
file configured with the filegen command.
Ordinarily, the stratum of a reference clock is zero, by
default. Since the xntpd daemon adds one to the stratum of
each peer, a primary server ordinarily displays stratum one.
In order to provide engineered backups, it is often useful
to specify the reference clock stratum as greater than zero.
The stratum option is used for this purpose. Also, in cases
involving both a reference clock and a 1-pps discipline sig-
nal, it is useful to specify the reference clock identifier
as other than the default, depending on the driver. The
refid option is used for this purpose. Except where noted,
these options apply to all clock drivers.
xntpd on Unix machines currently supports several different
types of clock hardware. It also supports a special
pseudo-clock used for backup or when no other clock source
is available. In the case of most of the clock drivers, sup-
port for a 1-pps precision timing signal is available as
described in the README file in the ./doc directory of the
xntp3 program distribution. The clock drivers, and the
addresses used to configure them, are described in the file,
README.refclocks, in the doc directory of the current pro-
gram distribution.
Variables
Most variables used by the NTP protocol can be examined with
ntpq (mode 6 messages). Currently very few variables can be
modified via mode 6 messages. These variables are either
created with the setvar directive or the leap warning vari-
ables. The leap warning bits that can be set in the
leapwarning variable (up to one month ahead). Both, the
leapwarning and in the leapindication variable, have a
slightly different encoding than the usual leap bits
interpretation:
00 The daemon passes the leap bits of its synchronization
source (usual mode of operation).
01/10 A leap second is added/deleted (operator forced leap
second).
11 Leap information from the synchronization source is
ignored (thus LEAP_NOWARNING is passed on).
FILES
/etc/inet/ntp.conf
Default name of the configuration file
/etc/ntp/ntp.drift
Conventional name of the drift file
/etc/inet/ntp.keys
Conventional name of the key file
/etc/inet/ntp.server
Sample server configuration file
ATTRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
____________________________________________________________
| ATTRIBUTE TYPE | ATTRIBUTE VALUE |
|_____________________________|_____________________________|
| Availability | SUNWntpu |
|_____________________________|_____________________________|
SEE ALSO
ntpdate(1M), ntpq(1M), ntptrace(1M), xntpdc(1M), rename(2),
attributes(5)
Man(1) output converted with
man2html