xntpd(1M) System Administration Commands xntpd(1M)NAMExntpd - Network Time Protocol daemon
SYNOPSIS
/usr/lib/inet/xntpd [-aAbdm] [-c conffile] [-e authdelay] [-f drift‐
file] [-k keyfile] [-l logfile] [-p pidfile] [-r broadcastdelay] [-s
statsdir] [-t trustedkey] [-v variable] [-V variable]
DESCRIPTIONxntpd 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 accuracy suitable for synchronizing with even the most pre‐
cise external time source.
Ordinarily, xntpd reads its configuration from a configuration 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 run‐
ning.
The daemon can operate in any of several modes, including symmetric
active/passive, client/server and broadcast/multicast. A broadcast/mul‐
ticast 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 environ‐
ment.
OPTIONS
The following command line arguments are understood by xntpd. See Con‐
figuration Commands for a more complete functional description:
-a Run in authentication mode.
-A Disable authentication mode.
-b Listen for broadcast NTP and sync to this if available.
-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 configura‐
tion files. Comments begin with a `#' character and extend to the end
of the line. Blank lines are ignored. Configuration commands consist of
an initial keyword followed by a list of arguments, separated by white‐
space. Some arguments may be optional. These commands may not be con‐
tinued over multiple lines. Arguments may be host names, host addresses
written in dotted−decimal, integers, floating point numbers (when spec‐
ifying times in seconds) and text strings.
Configuration Commands
In the following descriptions, optional arguments are delimited by
`[]', while alternatives are separated by `|'. The first three commands
specify various time servers to be used and time services to be pro‐
vided.
peer host_address [ key # ] [ version # ][ prefer ]
Specifies that the local server is to operate in "symmetric 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, depend‐
ing 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 outgo‐
ing 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 compa‐
rable 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 command. In this mode the local
server can be synchronized 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 multicastclient commands elsewhere
in this document. In broadcast mode the host_address is usually the
broadcast 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 multi‐
cast packets. Selection of the proper value, which
defaults to 127, is something of a black art and
must be coordinated with the network administra‐
tor(s).
broadcastclient
Directs the local server to listen for broadcast messages on the
local network, in order to discover other servers on the same sub‐
net. 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 syn‐
chronizes to succeeding broadcast messages. In order to avoid acci‐
dental 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 broadcastclient com‐
mand, but operates using IP multicasting. 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 frequency 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,
symbolic 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 unaf‐
fected. 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 off‐
set. This flag is useful in case
the local clock is controlled by
some other device or protocol and
NTP is used only to provide syn‐
chronization to other clients.
monitor disable Enables the monitoring facility
(see elsewhere).
stats enable Enables statistics facility file‐
gen (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 iden‐
tifiers which are trusted for the purposes of
authenticating peers suitable for synchroniza‐
tion. The authentication 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 argu‐
ments are 32 bit unsigned integers. Note, how‐
ever, that key 0 is fixed and globally known.
If meaningful authentication is to be per‐
formed, 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 problems that affect xntpd opera‐
tion. 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
authenticated. 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 configu‐
ration file, or if the keys don't match. These
requests are ignored.
Access Control Commands
restrict address [ mask numeric_mask ] [ flag ] [ ... ]
xntpd implements a general purpose address−and−mask based restric‐
tion 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 pack‐
ets. The source address of incoming packets is used for the match,
with the 32 bit address being logically and'ed with the mask asso‐
ciated with the restriction 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, mean‐
ing 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 normally given in dot‐
ted−quad format, the text string "default", with no mask option,
may be used to indicate 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 nei‐
ther queries nor time server polls will be
responded to.
noquery Ignore all NTP mode 7 packets (i.e., infor‐
mation 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 information 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 con‐
trol message protocol which is intended for
use by remote event logging programs.
lowpriotrap Declare traps set by matching hosts to be
low priority. The number of traps a server
can maintain 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 assignment algorithm by allow‐
ing 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 oth‐
erwise might be considered useful as future
synchronization partners.
notrust Treat these hosts normally in other
respects, but never use them as synchro‐
nization 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" pack‐
ets are not subject to client limitation
and therefore do not contribute 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 modi‐
fier, 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 speci‐
fied. The ntpport is considered more spe‐
cific 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 pre‐
vent the server from attempting to synchro‐
nize to its own time. A default entry is
also always present, though if it is other‐
wise unconfigured no flags are associated
with the default entry (i.e., everything
besides your own NTP server is unre‐
stricted).
The restriction facility was added to allow
the current access policies of the time
servers running 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 affect‐
ing your own. However, it should not be
considered an alternative to the standard
NTP authentication facility.
clientlimit limit Sets client_limit to limit; allows configu‐
ration of client limitation policy. This
variable defines the number of clients from
the same network that are allowed to use
the server.
clientperiod period Sets client_limit_period; allows configura‐
tion 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 statistics files
should be created (see below). This keyword allows the (otherwise
constant) filegen filename prefix to be modified for file genera‐
tion 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 outputs 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 midnight)
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 information. 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 fol‐
lowing 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 midnight)
3
The clock address in dotted-quad notation
4
The last timecode received from the clock in decoded ASCII for‐
mat, 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 generation 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. Generation file
sets provide a means for handling files that are continuously grow‐
ing during the lifetime of a server. Server statistics are a typi‐
cal 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 speci‐
fies when and how data will be directed to a new element of the
set. This way, information stored in elements of a file set that
are currently unused are available for administrational operations
without the risk of disturbing the operation of xntpd. (Most impor‐
tant: they can be removed to free space for new data produced.)
Filenames of set members are built from three elements:
prefix
This is a constant filename path. It is not subject to modifi‐
cations via the filegen statement. It is defined by the server,
usually specified as a compile time constant. It may, however,
be configurable for individual file generation sets via other
commands. For example, the prefix used with "loopstats" and
"peerstats" 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 component 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 following
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 provides an easy way of
separating files belonging to different xntpd server
incarnations. The set member filename is built by append‐
ing a `.' (dot) to concatenated 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 information written at December
10th, 1992 would end up in a file named, PrefixFile‐
name.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 generation set
are distinguished by appending the following 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 January, 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 num‐
ber.
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 running at the start of the cor‐
responding 24 hour period.
Information is only written to a file generation set when this set
is enabled. Output is prevented by specifying, disabled.
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 specify‐
ing 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 num‐
ber 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 example, network or
server access controls. This command specifies the default delay to
be used under these circumstances. Typically (for Ethernet), a num‐
ber 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_num‐
ber for sending messages with the specified local inter‐
face_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 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. Variables 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) command). Addi‐
tional variables serve informational purposes only. They can be
listed; but they are not related to the protocol. The known proto‐
col variables always override any variables defined via the setvar
mechanism.
Three special variables contain the names of all variable 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 com‐
mands. 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. configkeyword is formed by con‐
catenating the message class with the event class. It is permissi‐
ble to use the prefix, all, instead of a message class. A message
class may also be followed by the keyword, all, meaning to
enable/disable all of the respective message class. All configkey‐
words can be prefixed with the symbols, `=', `+' and `−' . Here,
`=' sets the syslogmask, `+' adds messages, and `−' removes mes‐
sages. 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 configkey‐
word:
Configkeyword
Message type
info
Informational messages control configuration information.
events
Event messages control logging of events (reachability, syn‐
chronization, 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 configuration could be useful:
logconfig =syncall +clockall
This configuration lists all clock information and synchronization
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 verification 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 authenticate an
association. The servers involved in an association 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 configuration file. While key num‐
ber 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 arbitrar‐
ily set in the keys file.
The key file uses the same comment conventions as the configuration
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 parity is
maintained for the octet. Leading zeroes must be speci‐
fied (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 ref‐
erence clocks. A reference clock is generally (though not always) a
radio timecode receiver which is synchronized to a source of standard
time such as the services offered by the NRC in Canada and NIST in the
U.S. The interface between the computer and the timecode receiver is
device 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 ref‐
erence clocks or peers. Clock addresses may generally 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 oth‐
erwise, time1 is used as a calibration constant to adjust the nomi‐
nal time offset of a particular clock to agree with an external
standard, such as a precision PPS signal. The specified offset is
in addition to the propagation delay provided by other means, such
as internal DIP switches.
stratum
Is a number in the range zero to 15 and is used to assign a non‐
standard 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 identifier to the clock.
flag1
flag2
flag3
flag4
Are binary flags used for customizing the clock driver. The inter‐
pretation of these values, and whether they are used at all, is a
function of the needs of the particular clock driver. However, by
convention, and unless indicated otherwise, flag3 invokes the TIOC‐
SPPS ioctl, while flag4 is used to enable recording verbose moni‐
toring data to the clockstats file configured with the filegen com‐
mand.
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 back‐
ups, 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, support 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 con‐
figure them, are described in the file, README.refclocks, in the doc
directory of the current program 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 variables. 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 attributes:
┌─────────────────────────────┬─────────────────────────────┐
│ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
├─────────────────────────────┼─────────────────────────────┤
│Availability │SUNWntpu │
└─────────────────────────────┴─────────────────────────────┘
SEE ALSOsvcs(1), ntpdate(1M), ntpq(1M), ntptrace(1M), svcadm(1M), xntpdc(1M),
rename(2), attributes(5), smf(5)NOTES
The xntpd service is managed by the service management facility,
smf(5), under the service identifier:
svc:/network/ntp:default
Administrative actions on this service, such as enabling, disabling, or
requesting restart, can be performed using svcadm(1M). The service's
status can be queried using the svcs(1) command.
SunOS 5.10 26 Jul 2004 xntpd(1M)
