home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Source Code 1993 July / THE_SOURCE_CODE_CD_ROM.iso / bsd_srcs / share / doc / smm / 08.timedop / timed.ms < prev    next >
Encoding:
Text File  |  1991-04-17  |  11.6 KB  |  280 lines
  1. .\" Copyright (c) 1986 The Regents of the University of California.
  2. .\" All rights reserved.
  3. .\"
  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.
  19. .\"
  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    6.3 (Berkeley) 4/17/91
  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
  62. .EH 'SMM:8-%''Timed Installation and Operation'
  63. .OH 'Timed Installation and Operation''SMM:8-%'
  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.
  280.