Commit | Line | Data |
---|---|---|
ad787160 C |
1 | .\" Copyright (c) 1986, 1993 |
2 | .\" The Regents of the University of California. All rights reserved. | |
bf8928b7 | 3 | .\" |
ad787160 C |
4 | .\" Redistribution and use in source and binary forms, with or without |
5 | .\" modification, are permitted provided that the following conditions | |
6 | .\" are met: | |
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. | |
409e5ca0 | 19 | .\" |
ad787160 C |
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 | |
30 | .\" SUCH DAMAGE. | |
31 | .\" | |
32 | .\" @(#)timed.ms 8.1 (Berkeley) 6/8/93 | |
bf8928b7 KM |
33 | .\" |
34 | .TL | |
35 | Timed Installation and Operation Guide | |
36 | .AU | |
37 | Riccardo Gusella, Stefano Zatti, James M. Bloom | |
38 | .AI | |
39 | Computer Systems Research Group | |
40 | Computer Science Division | |
41 | Department of Electrical Engineering and Computer Science | |
42 | University of California, Berkeley | |
43 | Berkeley, CA 94720 | |
44 | .AU | |
45 | Kirk Smith | |
46 | .AI | |
47 | Engineering Computer Network | |
48 | Department of Electrical Engineering | |
49 | Purdue University | |
50 | West Lafayette, IN 47906 | |
51 | .FS | |
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 | |
55 | Corporation of Italy. | |
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. | |
60 | .FE | |
61 | .LP | |
ad787160 C |
62 | .EH 'SMM:11-%''Timed Installation and Operation' |
63 | .OH 'Timed Installation and Operation''SMM:11-%' | |
bf8928b7 KM |
64 | .SH |
65 | Introduction | |
66 | .PP | |
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 | |
70 | area network. | |
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]. | |
75 | .PP | |
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. | |
87 | .PP | |
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.\** | |
93 | .FS | |
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]. | |
98 | .FE | |
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. | |
113 | .PP | |
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. | |
124 | .PP | |
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. | |
133 | .PP | |
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. | |
141 | .SH | |
142 | Guidelines | |
143 | .PP | |
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. | |
151 | .PP | |
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 | |
159 | master time daemons. | |
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. | |
167 | .PP | |
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. | |
175 | .PP | |
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 | |
181 | master time daemon. | |
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. | |
185 | .PP | |
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 | |
193 | networks X and Y. | |
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. | |
205 | .SH | |
206 | Installation | |
207 | .PP | |
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: | |
211 | .sp 2 | |
212 | .in 1i | |
213 | .nf | |
214 | if [ -f /etc/timed ]; then | |
215 | /etc/timed \fIflags\fP & echo -n ' timed' >/dev/console | |
216 | fi | |
217 | .fi | |
218 | .in -1i | |
219 | .sp | |
220 | .LP | |
221 | In any case, they must appear after the network | |
222 | is configured via ifconfig(8). | |
223 | .PP | |
224 | Also, the file \fI/etc/services\fP should contain the following | |
225 | line: | |
226 | .sp 2 | |
227 | .ti 1i | |
228 | timed 525/udp timeserver | |
229 | .sp | |
230 | .LP | |
231 | The \fIflags\fP are: | |
232 | .IP "-n network" 13 | |
233 | to consider the named network. | |
234 | .IP "-i network" | |
235 | to ignore the named network. | |
236 | .IP -t | |
237 | to place tracing information in \fI/usr/adm/timed.log\fP. | |
238 | .IP -M | |
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. | |
242 | .SH | |
243 | Daily Operation | |
244 | .PP | |
245 | \fITimedc(8)\fP is used to control the operation of the time daemon. | |
246 | It may be used to: | |
247 | .IP \(bu | |
248 | measure the differences between machines' clocks, | |
249 | .IP \(bu | |
250 | find the location where the master \fItimed\fP is running, | |
251 | .IP \(bu | |
252 | cause election timers on several machines to expire at the same time, | |
253 | .IP \(bu | |
254 | enable or disable tracing of messages received by \fItimed\fP. | |
255 | .LP | |
256 | See the manual page on \fItimed\fP\|(8) and \fItimedc\fP\|(8) | |
257 | for more detailed information. | |
258 | .PP | |
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). | |
262 | .bp | |
263 | .SH | |
264 | References | |
265 | .IP 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. | |
269 | .IP 2. | |
270 | R. Gusella and S. Zatti, \fIClock Synchronization in a Local Area Network\fP, | |
271 | University of California, Berkeley, Technical Report, \fIto appear\fP. | |
272 | .IP 3. | |
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. | |
276 | .IP 4. | |
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. |