1NTPD(8) Clockwatcher's Programming Manual NTPD(8)
2
6 ntpd - time synchronization daemon implementing NTP
7
9 ntpd [-d] [-s] [-t]
10
12 -d will bump the debug level by one. May be specified more than once
13 to increment debug level by one each time. Has no effect if ntpd has
14 not been compiled with DEBUG defined.
15 -s will cause ntpd to not adjust the the local clock.
17 -t will cause ntpd to modify the value of tickadj in your kernel. This
19 will have no effect unless ntpd was compiled with SETTICKADJ defined.
20
22 NTPD is the network time synchronization daemon and is normally invoked
23 at boot time from the /etc/rc(8) file. It implements a new revision of
24 the Network Time Protocol first described in RFC-958. It maintains the
25 host's time synchronized with a set of distributed time servers, each
26 with varying accurracy and reliability. Multiple time server masters
27 may exist, but there is no requirement for election of a single master.
28 Ntpd uses the adjtime(2) system call to slew the clock of the host by
30 small amount in order to keep the clock synchronized. If the local
31 clock exceeds the ``correct'' time by some threshold, then settimeof‐
32 day(2) is used to make a step adjustment of the local clock.
33 When ntpd(8) is started on the machine, it reads configuration informa‐
35 tion from /etc/ntp.conf which contains information about other ntp time
36 servers and host specific information. Configuration information is
37 listed one entry per line, with fields separated by whitespace. Lines
38 which begin with a ``#'' character are treated as comments. Here is a
39 sample configuration file:
40 #
41 # Local clock parameters
42 #
43 # Precision of the local clock to the nearest power of 2
44 # ex.
45 # 60-HZ = 2**-6
46 # 100-HZ = 2**-7
47 # 1000-HZ = 2**-10
48 precision -7
49 #
50 # intrinsic drift of local clock
51 #
52 tickadj 1
53 #
54 # Peers Type Name
55 #
56 peer foo.umd.edu
57 peer 192.5.39.94
58 peer bar.arpa
59 server bogon.umd.edu
60 passive bozo.umd.edu
61 There are two major types of information specified in the configuration
64 file: local host information, and remote timer server specification.
65 The local host information is used to describe the intrinsic properties
66 of the local host's timekeeping machinary. The commands in this group
67 are precision, and tickadj.
68 The precision command takes a number which describes the resolution of
70 the local clock, as a power of two. For example, a VAX system typi‐
71 cally has a 100 HZ clock and thus a precision of -7. If the symbol _hz
72 is defined in the namelist of /vmunix, this value is automatically set
73 based on the value of hz.
74 The tickadj command is used to specify the granularity of clock adjust‐
76 ment done by the adjtime(2) system call. If the -s option is specified
77 when ntpd is invoked, the kernel variable _tickadj is modified via
78 /dev/kmem. The preferred method of setting tickadj is by changing the
79 value in the kernel file conf.c instead of having ntpd set in this rude
80 fashion. On a VAX, a value of 1 is usually used. See the README file
81 for typical values of tickadj on various hardware platforms.
82 Currently three timer server specifications are supported. They are
84 peer, server and passive. Each command takes either a dotted-quad
85 internet address or a host name. Each host specified in any one of the
86 three commands is elligable to be synchronized to, while random hosts
87 which set up a peer relationship are not. The peer and server commands
88 create an active polling situation; in the case of peer, the NTP pack‐
89 ets are sourced in Symmetric-Active mode, while using server causes the
90 packets to be in Client mode. When reachability is lost with a config‐
91 ured host in either of these two cases, the daemon will continue to
92 poll to re-acquire that host. A host specified in the passive command
93 will not continue to be polled. If that host begins to poll us, it
94 will be eligable as to be synchronized but will not be polled if reach‐
95 ability is lost.
96 It is recommended that the bulk of the peers configured should be spec‐
98 ified with the client keyword; this will minimize resource usage on the
99 remote NTP server. If your host will be serving as a redistribution
100 point for a cluster of hosts, you should set up peer relationships
101 with higher quality clocks (lower stratums) and other equal stratum
102 clocks. In other words, if you are not redistributing time to others,
103 you shouldn't need to configure any peers in your NTP configuration;
104 client specifications are more appropriate.
105
107 Please choose your NTP peers carefully; send mail to ntp@TRAN‐
108 TOR.UMD.EDU for assitance.
109 There exists a broadcast command which will exercise completely
111 untested code. Use at your own risk.
112 There is no reason to believe that the hpux code which was added still
114 works. In general, this code and adaptations of the NTPD to platforms
115 without the adjtime(2) system call are not likely to be very satisfy‐
116 ing.
117
119 No doubt.
120
122 /etc/ntp.conf NTP daemon configuration file
123
125 adjtime(2), settimeofday(2), RFC-958, Network Time Protocol (Version 1)
126 Specification and Implementation, Revised 17 September 1988
127
129 Louis A. Mamakos, louie@TRANTOR.UMD.EDU
130 Michael G. Petry, petry@TRANTOR.UMD.EDU
131 The University of Maryland, Computer Science Center.
132LOCAL 27 November 1996 NTPD(8)