1 .\" Copyright (c) 1986, 1993
2 .\" The Regents of the University of California. All rights reserved.
4 .\" Redistribution and use in source and binary forms, with or without
5 .\" modification, are permitted provided that the following conditions
7 .\" 1. Redistributions of source code must retain the above copyright
8 .\" notice, this list of conditions and the following disclaimer.
9 .\" 2. Redistributions in binary form must reproduce the above copyright
10 .\" notice, this list of conditions and the following disclaimer in the
11 .\" documentation and/or other materials provided with the distribution.
12 .\" 3. All advertising materials mentioning features or use of this software
13 .\" must display the following acknowledgement:
14 .\" This product includes software developed by the University of
15 .\" California, Berkeley and its contributors.
16 .\" 4. Neither the name of the University nor the names of its contributors
17 .\" may be used to endorse or promote products derived from this software
18 .\" without specific prior written permission.
20 .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
21 .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
22 .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
23 .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
24 .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
25 .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
26 .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
27 .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
28 .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
29 .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
32 .\" @(#)timed.ms 8.1 (Berkeley) 6/8/93
35 Timed Installation and Operation Guide
37 Riccardo Gusella, Stefano Zatti, James M. Bloom
39 Computer Systems Research Group
40 Computer Science Division
41 Department of Electrical Engineering and Computer Science
42 University of California, Berkeley
47 Engineering Computer Network
48 Department of Electrical Engineering
50 West Lafayette, IN 47906
52 This work was sponsored by the Defense Advanced Research Projects Agency
53 (DoD), monitored by the Naval Electronics Systems
54 Command under contract No. N00039-84-C-0089, and by the CSELT
56 The views and conclusions contained in this document are those of the
57 authors and should not be interpreted as representing official policies,
58 either expressed or implied, of the Defense Research Projects Agency,
59 of the US Government, or of CSELT.
62 .EH 'SMM:11-%''Timed Installation and Operation'
63 .OH 'Timed Installation and Operation''SMM:11-%'
67 The clock synchronization service for
68 the UNIX 4.3BSD operating system is composed of a collection of
69 time daemons (\fItimed\fP) running on the machines in a local
71 The algorithms implemented by the service is based on a master-slave scheme.
72 The time daemons communicate with each other using the
73 \fITime Synchronization Protocol\fP (TSP) which
74 is built on the DARPA UDP protocol and described in detail in [4].
76 A time daemon has a twofold function.
77 First, it supports the synchronization of the clocks
78 of the various hosts in a local area network.
79 Second, it starts (or takes part in) the election that occurs
80 among slave time daemons when, for any reason, the master disappears.
81 The synchronization mechanism and the election procedure
82 employed by the program \fItimed\fP are described
83 in other documents [1,2,3].
84 The next paragraphs are a brief overview of how the time daemon works.
85 This document is mainly concerned with the administrative and technical
86 issues of running \fItimed\fP at a particular site.
88 A \fImaster time daemon\fP measures the time
89 differences between the clock of the machine on which it
90 is running and those of all other machines.
91 The master computes the \fInetwork time\fP as the average of the
92 times provided by nonfaulty clocks.\**
94 A clock is considered to be faulty when its value
95 is more than a small specified
96 interval apart from the majority of the clocks
97 of the other machines [1,2].
99 It then sends to each \fIslave time daemon\fP the
100 correction that should be performed on the clock of its machine.
101 This process is repeated periodically.
102 Since the correction is expressed as a time difference rather than an
103 absolute time, transmission delays do not interfere with
104 the accuracy of the synchronization.
105 When a machine comes up and joins the network,
106 it starts a slave time daemon which
107 will ask the master for the correct time and will reset the machine's clock
108 before any user activity can begin.
109 The time daemons are able to maintain a single network time in spite of
110 the drift of clocks away from each other.
111 The present implementation keeps processor clocks synchronized
112 within 20 milliseconds.
114 To ensure that the service provided is continuous and reliable,
115 it is necessary to implement an election algorithm to elect a
116 new master should the machine running the current master crash, the master
117 terminate (for example, because of a run-time error), or
118 the network be partitioned.
119 Under our algorithm, slaves are able to realize when the master has
120 stopped functioning and to elect a new master from among themselves.
121 It is important to note that, since the failure of the master results
122 only in a gradual divergence of clock values, the election
123 need not occur immediately.
125 The machines that are gateways between distinct local area
126 networks require particular care.
127 A time daemon on such machines may act as a \fIsubmaster\fP.
128 This artifact depends on the current inability of
129 transmission protocols to broadcast a message on a network
130 other than the one to which the broadcasting machine is connected.
131 The submaster appears as a slave on one network, and as a master
132 on one or more of the other networks to which it is connected.
134 A submaster classifies each network as one of three types.
135 A \fIslave network\fP is a network on which the submaster acts as a slave.
136 There can only be one slave network.
137 A \fImaster network\fP is a network on which the submaster acts as a master.
138 An \fIignored network\fP is any other network which already has a valid master.
139 The submaster tries periodically to become master on an ignored
140 network, but gives up immediately if a master already exists.
144 While the synchronization algorithm is quite general, the election
145 one, requiring a broadcast mechanism, puts constraints on
146 the kind of network on which time daemons can run.
147 The time daemon will only work on networks with broadcast capability
148 augmented with point-to-point links.
149 Machines that are only connected to point-to-point,
150 non-broadcast networks may not use the time daemon.
152 If we exclude submasters, there will normally be, at most, one master time
153 daemon in a local area internetwork.
154 During an election, only one of the slave time daemons
155 will become the new master.
156 However, because of the characteristics of its machine,
157 a slave can be prevented from becoming the master.
158 Therefore, a subset of machines must be designated as potential
160 A master time daemon will require CPU resources
161 proportional to the number of slaves, in general, more than
162 a slave time daemon, so it may be advisable to limit master time
163 daemons to machines with more powerful processors or lighter loads.
164 Also, machines with inaccurate clocks should not be used as masters.
165 This is a purely administrative decision: an organization may
166 well allow all of its machines to run master time daemons.
168 At the administrative level, a time daemon on a machine
169 with multiple network interfaces, may be told to ignore all
170 but one network or to ignore one network.
171 This is done with the \fI\-n network\fP and \fI\-i network\fP
172 options respectively at start-up time.
173 Typically, the time daemon would be instructed to ignore all but
174 the networks belonging to the local administrative control.
176 There are some limitations to the current
177 implementation of the time daemon.
178 It is expected that these limitations will be removed in future releases.
179 The constant NHOSTS in /usr/src/etc/timed/globals.h limits the
180 maximum number of machines that may be directly controlled by one
182 The current maximum is 29 (NHOSTS \- 1).
183 The constant must be changed and the program recompiled if a site wishes to
184 run \fItimed\fP on a larger (inter)network.
186 In addition, there is a \fIpathological situation\fP to
187 be avoided at all costs, that might occur when
188 time daemons run on multiply-connected local area networks.
189 In this case, as we have seen, time daemons running on gateway machines
190 will be submasters and they will act on some of those
191 networks as master time daemons.
192 Consider machines A and B that are both gateways between
194 If time daemons were started on both A and B without constraints, it would be
195 possible for submaster time daemon A to be a slave on network X
196 and the master on network Y, while submaster time daemon B is a slave on
197 network Y and the master on network X.
198 This \fIloop\fP of master time daemons will not function properly
199 or guarantee a unique time on both networks, and will cause
200 the submasters to use large amounts of system resources in the form
201 of network bandwidth and CPU time.
202 In fact, this kind of \fIloop\fP can also be generated with more
203 than two master time daemons,
204 when several local area networks are interconnected.
208 In order to start the time daemon on a given machine,
209 the following lines should be
210 added to the \fIlocal daemons\fP section in the file \fI/etc/rc.local\fP:
214 if [ -f /etc/timed ]; then
215 /etc/timed \fIflags\fP & echo -n ' timed' >/dev/console
221 In any case, they must appear after the network
222 is configured via ifconfig(8).
224 Also, the file \fI/etc/services\fP should contain the following
228 timed 525/udp timeserver
233 to consider the named network.
235 to ignore the named network.
237 to place tracing information in \fI/usr/adm/timed.log\fP.
239 to allow this time daemon to become a master.
240 A time daemon run without this option will be forced in the state of
241 slave during an election.
245 \fITimedc(8)\fP is used to control the operation of the time daemon.
248 measure the differences between machines' clocks,
250 find the location where the master \fItimed\fP is running,
252 cause election timers on several machines to expire at the same time,
254 enable or disable tracing of messages received by \fItimed\fP.
256 See the manual page on \fItimed\fP\|(8) and \fItimedc\fP\|(8)
257 for more detailed information.
259 The \fIdate(1)\fP command can be used to set the network date.
260 In order to set the time on a single machine, the \fI-n\fP flag
261 can be given to date(1).
266 R. Gusella and S. Zatti,
267 \fITEMPO: A Network Time Controller for Distributed Berkeley UNIX System\fP,
268 USENIX Summer Conference Proceedings, Salt Lake City, June 1984.
270 R. Gusella and S. Zatti, \fIClock Synchronization in a Local Area Network\fP,
271 University of California, Berkeley, Technical Report, \fIto appear\fP.
273 R. Gusella and S. Zatti,
274 \fIAn Election Algorithm for a Distributed Clock Synchronization Program\fP,
275 University of California, Berkeley, CS Technical Report #275, Dec. 1985.
277 R. Gusella and S. Zatti,
278 \fIThe Berkeley UNIX 4.3BSD Time Synchronization Protocol\fP,
279 UNIX Programmer's Manual, 4.3 Berkeley Software Distribution, Volume 2c.