NTPD(8) Clockwatcher's Programming Manual NTPD(8)
ntpd - time synchronization daemon implementing NTP
ntpd [-d] [-s] [-t]
-d will bump the debug level by one. May be specified more than once to increment debug
level by one each time. Has no effect if ntpd has not been compiled with DEBUG defined.
-s will cause ntpd to not adjust the the local clock.
-t will cause ntpd to modify the value of tickadj in your kernel. This will have no
effect unless ntpd was compiled with SETTICKADJ defined.
NTPD is the network time synchronization daemon and is normally invoked at boot time from
the /etc/rc(8) file. It implements a new revision of the Network Time Protocol first
described in RFC-958. It maintains the host's time synchronized with a set of distributed
time servers, each with varying accurracy and reliability. Multiple time server masters
may exist, but there is no requirement for election of a single master.
Ntpd uses the adjtime(2) system call to slew the clock of the host by small amount in
order to keep the clock synchronized. If the local clock exceeds the ``correct'' time by
some threshold, then settimeofday(2) is used to make a step adjustment of the local clock.
When ntpd(8) is started on the machine, it reads configuration information from
/etc/ntp.conf which contains information about other ntp time servers and host specific
information. Configuration information is listed one entry per line, with fields sepa-
rated by whitespace. Lines which begin with a ``#'' character are treated as comments.
Here is a sample configuration file:
# Local clock parameters
# Precision of the local clock to the nearest power of 2
# 60-HZ = 2**-6
# 100-HZ = 2**-7
# 1000-HZ = 2**-10
# intrinsic drift of local clock
# Peers Type Name
There are two major types of information specified in the configuration file: local host
information, and remote timer server specification. The local host information is used to
describe the intrinsic properties of the local host's timekeeping machinary. The commands
in this group are precision, and tickadj.
The precision command takes a number which describes the resolution of the local clock, as
a power of two. For example, a VAX system typically has a 100 HZ clock and thus a preci-
sion of -7. If the symbol _hz is defined in the namelist of /vmunix, this value is auto-
matically set based on the value of hz.
The tickadj command is used to specify the granularity of clock adjustment done by the
adjtime(2) system call. If the -s option is specified when ntpd is invoked, the kernel
variable _tickadj is modified via /dev/kmem. The preferred method of setting tickadj is
by changing the value in the kernel file conf.c instead of having ntpd set in this rude
fashion. On a VAX, a value of 1 is usually used. See the README file for typical values
of tickadj on various hardware platforms.
Currently three timer server specifications are supported. They are peer, server and pas-
sive. Each command takes either a dotted-quad internet address or a host name. Each host
specified in any one of the three commands is elligable to be synchronized to, while ran-
dom hosts which set up a peer relationship are not. The peer and server commands create
an active polling situation; in the case of peer, the NTP packets are sourced in Symmet-
ric-Active mode, while using server causes the packets to be in Client mode. When reacha-
bility is lost with a configured host in either of these two cases, the daemon will con-
tinue to poll to re-acquire that host. A host specified in the passive command will not
continue to be polled. If that host begins to poll us, it will be eligable as to be syn-
chronized but will not be polled if reachability is lost.
It is recommended that the bulk of the peers configured should be specified with the
client keyword; this will minimize resource usage on the remote NTP server. If your host
will be serving as a redistribution point for a cluster of hosts, you should set up peer
relationships with higher quality clocks (lower stratums) and other equal stratum clocks.
In other words, if you are not redistributing time to others, you shouldn't need to con-
figure any peers in your NTP configuration; client specifications are more appropriate.
Please choose your NTP peers carefully; send mail to ntp@TRANTOR.UMD.EDU for assitance.
There exists a broadcast command which will exercise completely untested code. Use at
your own risk.
There is no reason to believe that the hpux code which was added still works. In general,
this code and adaptations of the NTPD to platforms without the adjtime(2) system call are
not likely to be very satisfying.
/etc/ntp.conf NTP daemon configuration file
adjtime(2), settimeofday(2), RFC-958, Network Time Protocol (Version 1) Specification and
Implementation, Revised 17 September 1988
Louis A. Mamakos, louie@TRANTOR.UMD.EDU
Michael G. Petry, petry@TRANTOR.UMD.EDU
The University of Maryland, Computer Science Center.
LOCAL 27 November 1996 NTPD(8)