1 | <HTML><HEAD><TITLE> |
---|
2 | Notes on Configuring NTP and Setting up a NTP Subnet</H3> |
---|
3 | </TITLE></HEAD><BODY><H3> |
---|
4 | Notes on Configuring NTP and Setting up a NTP Subnet</H3> |
---|
5 | </H3> |
---|
6 | |
---|
7 | <img align=left src=pic/tonea.gif> |
---|
8 | From NBS Special Publication 432 (out of print) |
---|
9 | <br clear=left> |
---|
10 | |
---|
11 | <H4>Introduction</H4> |
---|
12 | |
---|
13 | This document is a collection of notes concerning the use of ntpd and |
---|
14 | relatedprograms, and on coping with the Network Time Protocol (NTP) in |
---|
15 | general. It is a major rewrite and update of an earlier document written |
---|
16 | by Dennis Ferguson of the University of Toronto and includes many |
---|
17 | changes and additions resulting from the NTP Version 3 specification and |
---|
18 | new Version 4 implementation features. It supersedes earlier documents, |
---|
19 | which should no longer be used |
---|
20 | for new configurations. |
---|
21 | |
---|
22 | <P><TT>ntpd</TT> includes a complete implementation of the NTP Version |
---|
23 | 3 specification, as defined in: |
---|
24 | |
---|
25 | <ul> |
---|
26 | |
---|
27 | <p><li>Mills, D.L. Network Time Protocol (Version 3) specification, |
---|
28 | implementation and analysis. Network Working Group Report RFC-1305, |
---|
29 | University of Delaware, March 1992, 113 pp. Abstract: <a |
---|
30 | href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.ps> |
---|
31 | PostScript</a> | <a |
---|
32 | href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.pdf> |
---|
33 | PDF</a>, Body: <a |
---|
34 | href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps> |
---|
35 | PostScript</a> | <a |
---|
36 | href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.pdf> |
---|
37 | PDF</a>, Appendices: <a |
---|
38 | href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.ps> |
---|
39 | PostScript</a> | <a |
---|
40 | href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.pdf> |
---|
41 | PDF</a> |
---|
42 | |
---|
43 | </ul> |
---|
44 | Additional features have are described for <A HREF="release.htm">NTP |
---|
45 | Version 4</A>. It also retains compatibility with both NTP Version 2, as |
---|
46 | defined in RFC-1119, and NTP Version 1, as defined in RFC-1059, although |
---|
47 | this compatibility is sometimes strained and only semiautomatic. In |
---|
48 | order to support in principle the ultimate precision of about 232 |
---|
49 | picoseconds in the NTP specification, <TT>ntpd</TT> uses NTP timestamp |
---|
50 | format for external communication and double precision floating point |
---|
51 | arithmetic internally. <TT>ntpd</TT> fully implements NTP Versions 2 and |
---|
52 | 3 authentication and in addition Version 4 autokey. It supports the NTP |
---|
53 | mode-6 control message facility along with a private mode-7 control- |
---|
54 | message facility used to remotely reconfigure the system and monitor a |
---|
55 | considerable amount of internal detail. As extensions to the |
---|
56 | specification, a flexible address-and-mask restriction facility has been |
---|
57 | included. |
---|
58 | |
---|
59 | <P>The code is biased towards the needs of a busy time server with |
---|
60 | numerous, often hundreds, of clients and other servers. Tables are |
---|
61 | hashed to allow efficient handling of many associations, though at the |
---|
62 | expense of additional overhead when the number of associations is small. |
---|
63 | Many fancy features have been included to permit efficient management |
---|
64 | and monitoring of a busy primary server, features which are probably |
---|
65 | excess baggage for a high stratum client. In such cases, a stripped-down |
---|
66 | version of the protocol, the Simple Network Time Protocol (SNTP) can be |
---|
67 | used. SNTP and NTP servers and clients can interwork in most situations, |
---|
68 | as described in: Mills, D.L. Simple Network Time Protocol (SNTP). |
---|
69 | Network Working Group Report RFC-2030, University of Delaware, October |
---|
70 | 1996, 14 pp. <A |
---|
71 | HREF="http://www.eecis.udel.edu/~mills/database/rfc2030.txt"> |
---|
72 | (ASCII)</A>. |
---|
73 | |
---|
74 | <P>The code was written with near demonic attention to details which can |
---|
75 | affect precision and as a consequence should be able to make good use of |
---|
76 | high performance, special purpose hardware such as precision oscillators |
---|
77 | and radio clocks. The present code supports a number of radio clocks, |
---|
78 | including those for the WWV, CHU, WWVB, MSF, DCF77, GOES and GPS radio |
---|
79 | and satellite time services and USNO, ACTS and PTB modem time services. |
---|
80 | It also supports the IRIG-B and IRIG-E signal format connected via an |
---|
81 | audio codec. The server methodically avoids the use of Unix-specific |
---|
82 | library routines where possible by implementing local versions, in order |
---|
83 | to aid in porting the code to perverse Unix and non-Unix platforms. |
---|
84 | |
---|
85 | <P>While this implementation conforms in most respects to the NTP |
---|
86 | Version 3 specification RFC-1305, a number of improvements have been |
---|
87 | made which are described in the conformance statement in the <A |
---|
88 | HREF="biblio.htm">Further Information and Bibliography</A> page. It has |
---|
89 | been specifically tuned to achieve the highest accuracy possible on |
---|
90 | whatever hardware and operating-system platform is available. In |
---|
91 | general, its precision and stability are limited only by the |
---|
92 | characteristics of the onboard clock source used by the hardware |
---|
93 | and operating system, usually an uncompensated crystal oscillator. On |
---|
94 | modern RISC-based processors connected directly to radio clocks via |
---|
95 | serial-asynchronous interfaces, the accuracy is usually limited by the |
---|
96 | radio clock and interface to the order of a millisecond or less. The |
---|
97 | code includes special features to support a pulse-per-second (PPS) |
---|
98 | signal and/or an IRIG-B signal generated by some radio clocks. When used |
---|
99 | in conjunction with a suitable hardware level converter, the accuracy |
---|
100 | can be improved to a few tens of microseconds. |
---|
101 | Further improvement is possible using an outboard, stabilized frequency |
---|
102 | source, in which the accuracy and stability are limited only by the |
---|
103 | characteristics |
---|
104 | of that source. |
---|
105 | |
---|
106 | <P>The NTP Version 4 distribution includes, in addition to the daemon |
---|
107 | itself (<TT><A HREF="ntpd.htm">ntpd</A></TT>), several utility programs, |
---|
108 | including two remote-monitoring programs (<A HREF="ntpq.htm"> |
---|
109 | <TT>ntpq</TT></A>, <TT><A HREF="ntpdc.htm">ntpdc</A></TT>), a remote |
---|
110 | clock-setting program similar to the Unix rdate program |
---|
111 | (<TT>ntpdate</TT>), a traceback utility u seful to discover suitable |
---|
112 | synchronization sources (<TT>ntptrace</TT>), and various programs used |
---|
113 | to configure the local platform and calibrate the intrinsic errors. NTP |
---|
114 | has been ported to a large number of platforms, including most RISC and |
---|
115 | CISC workstations and mainframes manufactured today. Example |
---|
116 | configuration files for many models of these machines are included |
---|
117 | in the distribution. While in most cases the standard version of the |
---|
118 | implementation runs with no hardware or operating system modifications, |
---|
119 | not all features of the distribution are available on all platforms. For |
---|
120 | instance, a special feature allowing Sun workstations to achieve |
---|
121 | accuracies in the order of 100 microseconds requires some minor changes |
---|
122 | and additions to the kernel and input/output support. |
---|
123 | |
---|
124 | <P>There are, however, several drawbacks to all of this. <TT>ntpd</TT> |
---|
125 | is quite fat. This is rotten if your intended platform for the daemon is |
---|
126 | memory limited. <TT>ntpd</TT> uses <TT>SIGIO</TT> for all input, a |
---|
127 | facility which appears to not enjoy universal support and whose use |
---|
128 | seems to exercise the parts of your vendors' kernels which are most |
---|
129 | likely to have been done poorly. The code is unforgiving in the face of |
---|
130 | kernel problems which affect performance, and generally requires that |
---|
131 | you repair the problems in order to achieve acceptable performance. The |
---|
132 | code has a distinctly experimental flavour and contains features which |
---|
133 | could charitably be termed failed |
---|
134 | experiments, but which have not been completely hacked out. Much was |
---|
135 | learned from the addition of support for a variety of radio clocks, |
---|
136 | with the result that some radio clock drivers could use some rewriting. |
---|
137 | |
---|
138 | <H4>How NTP Works</H4> |
---|
139 | |
---|
140 | The approach used by NTP to achieve reliable time synchronization from |
---|
141 | a set of possibly unreliable remote time servers is somewhat different |
---|
142 | than other protocols. In particular, NTP does not attempt to synchronize |
---|
143 | clocks to each other. Rather, each server attempts to synchronize to |
---|
144 | Universal |
---|
145 | Coordinated Time (UTC) using the best available source and available |
---|
146 | transmission |
---|
147 | paths to that source. This is a fine point which is worth understanding. |
---|
148 | A group of NTP-synchronized clocks may be close to each other in time, |
---|
149 | but this is not a consequence of the clocks in the group having |
---|
150 | synchronized |
---|
151 | to each other, but rather because each clock has synchronized closely to |
---|
152 | UTC via the best source it has access to. As such, trying to synchronize |
---|
153 | a set of clocks to a set of servers whose time is not in mutual |
---|
154 | agreement |
---|
155 | may not result in any sort of useful synchronization of the clocks, even |
---|
156 | if you don't care about UTC. However, in networks isolated from UTC |
---|
157 | sources, |
---|
158 | provisions can made to nominate one of them as a phantom UTC source. |
---|
159 | |
---|
160 | <P>NTP operates on the premise that there is one true standard time, and |
---|
161 | that if several servers which claim synchronization to standard time |
---|
162 | disagree |
---|
163 | about what that time is, then one or more of them must be broken. There |
---|
164 | is no attempt to resolve differences more gracefully since the premise |
---|
165 | is that substantial differences cannot exist. In essence, NTP expects |
---|
166 | that |
---|
167 | the time being distributed from the root of the synchronization subnet |
---|
168 | will be derived from some external source of UTC (e.g., a radio clock). |
---|
169 | This makes it somewhat inconvenient (though by no means impossible) to |
---|
170 | synchronize hosts together without a reliable source of UTC to |
---|
171 | synchronize |
---|
172 | them to. If your network is isolated and you cannot access other |
---|
173 | people's |
---|
174 | servers across the Internet, a radio clock may make a good investment. |
---|
175 | |
---|
176 | <P>Time is distributed through a hierarchy of NTP servers, with each |
---|
177 | server |
---|
178 | adopting a <I>stratum</I> which indicates how far away from an external |
---|
179 | source of UTC it is operating at. Stratum-1 servers, which are at the |
---|
180 | top |
---|
181 | of the pile (or bottom, depending on your point of view), have access to |
---|
182 | some external time source, usually a radio clock synchronized to time |
---|
183 | signal |
---|
184 | broadcasts from radio stations which explicitly provide a standard time |
---|
185 | service. A stratum-2 server is one which is currently obtaining time |
---|
186 | from |
---|
187 | a stratum-1 server, a stratum-3 server gets its time from a stratum-2 |
---|
188 | server, |
---|
189 | and so on. To avoid long lived synchronization loops the number of |
---|
190 | strata |
---|
191 | is limited to 15. |
---|
192 | |
---|
193 | <P>Each client in the synchronization subnet (which may also be a server |
---|
194 | for other, higher stratum clients) chooses exactly one of the available |
---|
195 | servers to synchronize to, usually from among the lowest stratum servers |
---|
196 | it has access to. This is, however, not always an optimal configuration, |
---|
197 | for indeed NTP operates under another premise as well, that each |
---|
198 | server's |
---|
199 | time should be viewed with a certain amount of distrust. NTP really |
---|
200 | prefers |
---|
201 | to have access to several sources of lower stratum time (at least three) |
---|
202 | since it can then apply an agreement algorithm to detect insanity on the |
---|
203 | part of any one of these. Normally, when all servers are in agreement, |
---|
204 | NTP will choose the best of these, where "best" is defined in terms of |
---|
205 | lowest stratum, closest (in terms of network delay) and claimed |
---|
206 | precision, |
---|
207 | along with several other considerations. The implication is that, while |
---|
208 | one should aim to provide each client with three or more sources of |
---|
209 | lower |
---|
210 | stratum time, several of these will only be providing backup service and |
---|
211 | may be of lesser quality in terms of network delay and stratum (i.e., a |
---|
212 | same-stratum peer which receives time from lower stratum sources the |
---|
213 | local |
---|
214 | server doesn't access directly can also provide good backup service). |
---|
215 | |
---|
216 | <P>Finally, there is the issue of association modes. There are a number |
---|
217 | of modes in which NTP servers can associate with each other, with the |
---|
218 | mode |
---|
219 | of each server in the pair indicating the behaviour the other server can |
---|
220 | expect from it. In particular, when configuring a server to obtain time |
---|
221 | from other servers, there is a choice of two modes which may be used. |
---|
222 | Configuring |
---|
223 | an association in symmetric-active mode (usually indicated by a |
---|
224 | <TT>peer</TT> |
---|
225 | declaration in the configuration file) indicates to the remote server |
---|
226 | that |
---|
227 | one wishes to obtain time from the remote server and that one is also |
---|
228 | willing |
---|
229 | to supply time to the remote server if need be. This mode is appropriate |
---|
230 | in configurations involving a number of redundant time servers |
---|
231 | interconnected |
---|
232 | via diverse network paths, which is presently the case for most stratum- |
---|
233 | 1 |
---|
234 | and stratum-2 servers on the Internet today. Configuring an association |
---|
235 | in client mode (usually indicated by a <TT>server</TT> declaration in |
---|
236 | the |
---|
237 | configuration file) indicates that one wishes to obtain time from the |
---|
238 | remote |
---|
239 | server, but that one is not willing to provide time to the remote |
---|
240 | server. |
---|
241 | This mode is appropriate for file-server and workstation clients that do |
---|
242 | not provide synchronization to other local clients. Client mode is also |
---|
243 | useful for boot-date-setting programs and the like, which really have no |
---|
244 | time to provide and which don't retain state about associations over the |
---|
245 | longer term. |
---|
246 | |
---|
247 | <P>Where the requirements in accuracy and reliability are modest, |
---|
248 | clients |
---|
249 | can be configured to use broadcast and/or multicast modes. These modes |
---|
250 | are not normally utilized by servers with dependent clients. The |
---|
251 | advantage |
---|
252 | of these modes is that clients do not need to be configured for a |
---|
253 | specific |
---|
254 | server, so that all clients operating can use the same configuration |
---|
255 | file. |
---|
256 | Broadcast mode requires a broadcast server on the same subnet, while |
---|
257 | multicast |
---|
258 | mode requires support for IP multicast on the client machine, as well as |
---|
259 | connectivity via the MBONE to a multicast server. Since broadcast |
---|
260 | messages |
---|
261 | are not propagated by routers, only those broadcast servers on the same |
---|
262 | subnet will be used. There is at present no way to select which of |
---|
263 | possibly |
---|
264 | many multicast servers will be used, since all operate on the same group |
---|
265 | address. |
---|
266 | |
---|
267 | <P>Where the maximum accuracy and reliability provided by NTP are |
---|
268 | needed, |
---|
269 | clients and servers operate in either client/server or symmetric modes. |
---|
270 | Symmetric modes are most often used between two or more servers |
---|
271 | operating |
---|
272 | as a mutually redundant group. In these modes, the servers in the group |
---|
273 | members arrange the synchronization paths for maximum performance, |
---|
274 | depending |
---|
275 | on network jitter and propagation delay. If one or more of the group |
---|
276 | members |
---|
277 | fail, the remaining members automatically reconfigure as required. |
---|
278 | Dependent |
---|
279 | clients and servers normally operate in client/server mode, in which a |
---|
280 | client or dependent server can be synchronized to a group member, but no |
---|
281 | group member can synchronize to the client or dependent server. This |
---|
282 | provides |
---|
283 | protection against malfunctions or protocol attacks. |
---|
284 | |
---|
285 | <P>Servers that provide synchronization to a sizeable population of |
---|
286 | clients |
---|
287 | normally operate as a group of three or more mutually redundant servers, |
---|
288 | each operating with three or more stratum-one or stratum-two servers in |
---|
289 | client-server modes, as well as all other members of the group in |
---|
290 | symmetric |
---|
291 | modes. This provides protection against malfunctions in which one or |
---|
292 | more |
---|
293 | servers fail to operate or provide incorrect time. The NTP algorithms |
---|
294 | have |
---|
295 | been specifically engineered to resist attacks where some fraction of |
---|
296 | the |
---|
297 | configured synchronization sources accidently or purposely provide |
---|
298 | incorrect |
---|
299 | time. In these cases a special voting procedure is used to identify |
---|
300 | spurious |
---|
301 | sources and discard their data. |
---|
302 | <H4> |
---|
303 | Configuring Your Subnet</H4> |
---|
304 | At startup time the <TT>ntpd</TT> daemon running on a host reads the |
---|
305 | initial |
---|
306 | configuration information from a file, usually <TT>/etc/ntp.conf</TT>, |
---|
307 | unless a different name has been specified at compile time. Putting |
---|
308 | something |
---|
309 | in this file which will enable the host to obtain time from somewhere |
---|
310 | else |
---|
311 | is usually the first big hurdle after installation of the software |
---|
312 | itself, |
---|
313 | which is described in the <A HREF="build.htm">Building and Installing |
---|
314 | the |
---|
315 | Distribution</A> page. At its simplest, what you need to do in the |
---|
316 | configuration |
---|
317 | file is declare the servers that the daemon should poll for time |
---|
318 | synchronization. |
---|
319 | In principle, no such list is needed if some other time server operating |
---|
320 | in broadcast/multicast mode is available, which requires the client to |
---|
321 | operate in a broadcastclient mode. |
---|
322 | |
---|
323 | <P>In the case of a workstation operating in an enterprise network for |
---|
324 | a public or private organization, there is often an administrative |
---|
325 | department |
---|
326 | that coordinates network services, including NTP. Where available, the |
---|
327 | addresses of appropriate servers can be provided by that department. |
---|
328 | However, |
---|
329 | if this infrastructure is not available, it is necessary to explore some |
---|
330 | portion of the existing NTP subnet now running in the Internet. There |
---|
331 | are |
---|
332 | at present many thousands of time servers running NTP in the Internet, |
---|
333 | a significant number of which are willing to provide a public time- |
---|
334 | synchronization |
---|
335 | service. Some of these are listed in the list of public time servers, |
---|
336 | which |
---|
337 | can be accessed via the <A HREF="http://www.eecis.udel.edu/~ntp">NTP web |
---|
338 | page</A>. These data are updated on a regular basis using information |
---|
339 | provided |
---|
340 | voluntarily by various site administrators. There are other ways to |
---|
341 | explore |
---|
342 | the nearby subnet using the <TT><A HREF="ntptrace.htm">ntptrace</A></TT> |
---|
343 | and <TT><A HREF="ntpdc.htm">ntpdc</A></TT> programs. |
---|
344 | |
---|
345 | <P>It is vital to carefully consider the issues of robustness and |
---|
346 | reliability |
---|
347 | when selecting the sources of synchronization. Normally, not less than |
---|
348 | three sources should be available, preferably selected to avoid common |
---|
349 | points of failure. It is usually better to choose sources which are |
---|
350 | likely |
---|
351 | to be "close" to you in terms of network topology, though you shouldn't |
---|
352 | worry overly about this if you are unable to determine who is close and |
---|
353 | who isn't. Normally, it is much more serious when a server becomes |
---|
354 | faulty |
---|
355 | and delivers incorrect time than when it simply stops operating, since |
---|
356 | an NTP-synchronized host normally can coast for hours or even days |
---|
357 | without |
---|
358 | its clock accumulating serious error approaching a second, for instance. |
---|
359 | Selecting at least three sources from different operating |
---|
360 | administrations, |
---|
361 | where possible, is the minimum recommended, although a lesser number |
---|
362 | could |
---|
363 | provide acceptable service with a degraded degree of robustness. |
---|
364 | |
---|
365 | <P>Normally, it is not considered good practice for a single workstation |
---|
366 | to request synchronization from a primary (stratum-1) time server. At |
---|
367 | present, |
---|
368 | these servers provide synchronization for hundreds of clients in many |
---|
369 | cases |
---|
370 | and could, along with the network access paths, become seriously |
---|
371 | overloaded |
---|
372 | if large numbers of workstation clients requested synchronization |
---|
373 | directly. |
---|
374 | Therefore, workstations located in sparsely populated administrative |
---|
375 | domains |
---|
376 | with no local synchronization infrastructure should request |
---|
377 | synchronization |
---|
378 | from nearby stratum-2 servers instead. In most cases the keepers of |
---|
379 | those |
---|
380 | servers in the lists of public servers provide unrestricted access |
---|
381 | without |
---|
382 | prior permission; however, in all cases it is considered polite to |
---|
383 | notify |
---|
384 | the administrator listed in the file upon commencement of regular |
---|
385 | service. |
---|
386 | In all cases the access mode and notification requirements listed in the |
---|
387 | file must be respected. Under no conditions should servers not in these |
---|
388 | lists be used without prior permission, as to do so can create severe |
---|
389 | problems |
---|
390 | in the local infrastructure, especially in cases of dial-up access to |
---|
391 | the |
---|
392 | Internet. |
---|
393 | |
---|
394 | <P>In the case of a gateway or file server providing service to a |
---|
395 | significant |
---|
396 | number of workstations or file servers in an enterprise network it is |
---|
397 | even |
---|
398 | more important to provide multiple, redundant sources of synchronization |
---|
399 | and multiple, diversity-routed, network access paths. The preferred |
---|
400 | configuration |
---|
401 | is at least three administratively coordinated time servers providing |
---|
402 | service |
---|
403 | throughout the administrative domain including campus networks and |
---|
404 | subnetworks. |
---|
405 | Each of these should obtain service from at least two different outside |
---|
406 | sources of synchronization, preferably via different gateways and access |
---|
407 | paths. These sources should all operate at the same stratum level, which |
---|
408 | is one less than the stratum level to be used by the local time servers |
---|
409 | themselves. In addition, each of these time servers should peer with all |
---|
410 | of the other time servers in the local administrative domain at the |
---|
411 | stratum |
---|
412 | level used by the local time servers, as well as at least one |
---|
413 | (different) |
---|
414 | outside source at this level. This configuration results in the use of |
---|
415 | six outside sources at a lower stratum level (toward the primary source |
---|
416 | of synchronization, usually a radio clock), plus three outside sources |
---|
417 | at the same stratum level, for a total of nine outside sources of |
---|
418 | synchronization. |
---|
419 | While this may seem excessive, the actual load on network resources is |
---|
420 | minimal, since the interval between polling messages exchanged between |
---|
421 | peers usually ratchets back to no more than one message every 17 |
---|
422 | minutes. |
---|
423 | |
---|
424 | <P>The stratum level to be used by the local time servers is an |
---|
425 | engineering |
---|
426 | choice. As a matter of policy, and in order to reduce the load on the |
---|
427 | primary |
---|
428 | servers, it is desirable to use the highest stratum consistent with |
---|
429 | reliable, |
---|
430 | accurate time synchronization throughout the administrative domain. In |
---|
431 | the case of enterprise networks serving hundreds or thousands of client |
---|
432 | file servers and workstations, conventional practice is to obtain |
---|
433 | service |
---|
434 | from stratum-1 primary servers listed for public access. When choosing |
---|
435 | sources away from the primary sources, the particular synchronization |
---|
436 | path |
---|
437 | in use at any time can be verified using the <TT>ntptrace</TT> program |
---|
438 | included in this distribution. It is important to avoid loops and |
---|
439 | possible |
---|
440 | common points of failure when selecting these sources. Note that, while |
---|
441 | NTP detects and rejects loops involving neighboring servers, it does not |
---|
442 | detect loops involving intervening servers. In the unlikely case that |
---|
443 | all |
---|
444 | primary sources of synchronization are lost throughout the subnet, the |
---|
445 | remaining servers on that subnet can form temporary loops and, if the |
---|
446 | loss |
---|
447 | continues for an interval of many hours, the servers will drop off the |
---|
448 | subnet and free-run with respect to their internal (disciplined) timing |
---|
449 | sources. After some period with no outside timing source (currently one |
---|
450 | day), a host will declare itself unsynchronized and provide this |
---|
451 | information |
---|
452 | to local application programs. |
---|
453 | |
---|
454 | <P>In many cases the purchase of one or more radio clocks is justified, |
---|
455 | in which cases good engineering practice is to use the configurations |
---|
456 | described |
---|
457 | above anyway and connect the radio clock to one of the local servers. |
---|
458 | This |
---|
459 | server is then encouraged to participate in a special primary-server |
---|
460 | subnetwork |
---|
461 | in which each radio-equipped server peers with several other similarly |
---|
462 | equipped servers. In this way the radio-equipped server may provide |
---|
463 | synchronization, |
---|
464 | as well as receive synchronization, should the local or remote radio |
---|
465 | clock(s) |
---|
466 | fail or become faulty. <TT>ntpd</TT> treats attached radio clock(s) in |
---|
467 | the same way as other servers and applies the same criteria and |
---|
468 | algorithms |
---|
469 | to the time indications, so can detect when the radio fails or becomes |
---|
470 | faulty and switch to alternate sources of synchronization. It is |
---|
471 | strongly |
---|
472 | advised, and in practice for most primary servers today, to employ the |
---|
473 | authentication or access-control features of the NTP specification in |
---|
474 | order |
---|
475 | to protect against hostile intruders and possible destabilization of the |
---|
476 | time service. Using this or similar strategies, the remaining hosts in |
---|
477 | the same administrative domain can be synchronized to the three (or |
---|
478 | more) |
---|
479 | selected time servers. Assuming these servers are synchronized directly |
---|
480 | to stratum-1 sources and operate normally as stratum-2, the next level |
---|
481 | away from the primary source of synchronization, for instance various |
---|
482 | campus |
---|
483 | file servers, will operate at stratum 3 and dependent workstations at |
---|
484 | stratum |
---|
485 | 4. Engineered correctly, such a subnet will survive all but the most |
---|
486 | exotic |
---|
487 | failures or even hostile penetrations of the various, distributed |
---|
488 | timekeeping |
---|
489 | resources. |
---|
490 | <P>The above arrangement should provide very good, robust time service |
---|
491 | with a minimum of traffic to distant servers and with manageable loads |
---|
492 | on the local servers. While it is theoretically possible to extend the |
---|
493 | synchronization subnet to even higher strata, this is seldom justified |
---|
494 | and can make the maintenance of configuration files unmanageable. |
---|
495 | Serving |
---|
496 | time to a higher stratum peer is very inexpensive in terms of the load |
---|
497 | on the lower stratum server if the latter is located on the same |
---|
498 | concatenated |
---|
499 | LAN. When justified by the accuracy expectations, NTP can be operated in |
---|
500 | broadcast and multicast modes, so that clients need only listen for |
---|
501 | periodic |
---|
502 | broadcasts and do not need to send anything. |
---|
503 | |
---|
504 | <P>When planning your network you might, beyond this, keep in mind a few |
---|
505 | generic don'ts, in particular: |
---|
506 | <UL> |
---|
507 | <LI> |
---|
508 | Don't synchronize a local time server to another peer at the same |
---|
509 | stratum, |
---|
510 | unless the latter is receiving time from lower stratum sources the |
---|
511 | former |
---|
512 | doesn't talk to directly. This minimizes the occurrence of common points |
---|
513 | of failure, but does not eliminate them in cases where the usual chain |
---|
514 | of associations to the primary sources of synchronization are disrupted |
---|
515 | due to failures.</LI> |
---|
516 | |
---|
517 | <BR> |
---|
518 | <LI> |
---|
519 | Don't configure peer associations with higher stratum servers. Let the |
---|
520 | higher strata configure lower stratum servers, but not the reverse. This |
---|
521 | greatly simplifies configuration file maintenance, since there is |
---|
522 | usually |
---|
523 | much greater configuration churn in the high stratum clients such as |
---|
524 | personal |
---|
525 | workstations.</LI> |
---|
526 | <BR> |
---|
527 | <LI> |
---|
528 | Don't synchronize more than one time server in a particular |
---|
529 | administrative |
---|
530 | domain to the same time server outside that domain. Such a practice |
---|
531 | invites |
---|
532 | common points of failure, as well as raises the possibility of massive |
---|
533 | abuse, should the configuration file be automatically distributed do a |
---|
534 | large number of clients.</LI> |
---|
535 | </UL> |
---|
536 | There are many useful exceptions to these rules. When in doubt, however, |
---|
537 | follow them. |
---|
538 | <H4> |
---|
539 | Configuring Your Server or Client</H4> |
---|
540 | As mentioned previously, the configuration file is usually called |
---|
541 | /etc/ntp.conf. |
---|
542 | This is an ASCII file conforming to the usual comment and whitespace |
---|
543 | conventions. |
---|
544 | A working configuration file might look like (in this and other |
---|
545 | examples, |
---|
546 | do not copy this directly): |
---|
547 | <PRE> # peer configuration for host whimsy |
---|
548 | # (expected to operate at stratum 2) |
---|
549 | |
---|
550 | server rackety.udel.edu |
---|
551 | server umd1.umd.edu |
---|
552 | server lilben.tn.cornell.edu |
---|
553 | |
---|
554 | driftfile /etc/ntp.drift</PRE> |
---|
555 | (Note the use of host names, although host addresses in dotted-quad |
---|
556 | notation |
---|
557 | can also be used. It is always preferable to use names rather than |
---|
558 | addresses, |
---|
559 | since over time the addresses can change, while the names seldom |
---|
560 | change.) |
---|
561 | |
---|
562 | <P>This particular host is expected to operate as a client at stratum 2 |
---|
563 | by virtue of the <TT>server</TT> keyword and the fact that two of the |
---|
564 | three |
---|
565 | servers declared (the first two) have radio clocks and usually run at |
---|
566 | stratum |
---|
567 | 1. The third server in the list has no radio clock, but is known to |
---|
568 | maintain |
---|
569 | associations with a number of stratum 1 peers and usually operates at |
---|
570 | stratum |
---|
571 | 2. Of particular importance with the last host is that it maintains |
---|
572 | associations |
---|
573 | with peers besides the two stratum 1 peers mentioned. This can be |
---|
574 | verified |
---|
575 | using the <TT>ntpq</TT> program mentioned above. When configured using |
---|
576 | the <TT>server</TT> keyword, this host can receive synchronization from |
---|
577 | any of the listed servers, but can never provide synchronization to |
---|
578 | them. |
---|
579 | |
---|
580 | <P>Unless restricted using facilities described later, this host can |
---|
581 | provide |
---|
582 | synchronization to dependent clients, which do not have to be listed in |
---|
583 | the configuration file. Associations maintained for these clients are |
---|
584 | transitory |
---|
585 | and result in no persistent state in the host. These clients are |
---|
586 | normally |
---|
587 | not visible using the <TT>ntpq</TT> program included in the |
---|
588 | distribution; |
---|
589 | however, <TT>ntpd</TT> includes a monitoring feature (described later) |
---|
590 | which caches a minimal amount of client information useful for debugging |
---|
591 | administrative purposes. |
---|
592 | |
---|
593 | <P>A time server expected to both receive synchronization from another |
---|
594 | server, as well as to provide synchronization to it, is declared using |
---|
595 | the <TT>peer</TT> keyword instead of the <TT>server</TT> keyword. In all |
---|
596 | other aspects the server operates the same in either mode and can |
---|
597 | provide |
---|
598 | synchronization to dependent clients or other peers. If a local source |
---|
599 | of UTC time is available, it is considered good engineering practice to |
---|
600 | declare time servers outside the administrative domain as <TT>peer</TT> |
---|
601 | and those inside as <TT>server</TT> in order to provide redundancy in |
---|
602 | the |
---|
603 | global Internet, while minimizing the possibility of instability within |
---|
604 | the domain itself. A time server in one domain can in principle heal |
---|
605 | another |
---|
606 | domain temporarily isolated from all other sources of synchronization. |
---|
607 | However, it is probably unwise for a casual workstation to bridge |
---|
608 | fragments |
---|
609 | of the local domain which have become temporarily isolated. |
---|
610 | |
---|
611 | <P>Note the inclusion of a <TT>driftfile</TT> declaration. One of the |
---|
612 | things |
---|
613 | the NTP daemon does when it is first started is to compute the error in |
---|
614 | the intrinsic frequency of the clock on the computer it is running on. |
---|
615 | It usually takes about a day or so after the daemon is started to |
---|
616 | compute |
---|
617 | a good estimate of this (and it needs a good estimate to synchronize |
---|
618 | closely |
---|
619 | to its server). Once the initial value is computed, it will change only |
---|
620 | by relatively small amounts during the course of continued operation. |
---|
621 | The |
---|
622 | <TT>driftfile</TT> declaration indicates to the daemon the name of a |
---|
623 | file |
---|
624 | where it may store the current value of the frequency error so that, if |
---|
625 | the daemon is stopped and restarted, it can reinitialize itself to the |
---|
626 | previous estimate and avoid the day's worth of time it will take to |
---|
627 | recompute |
---|
628 | the frequency estimate. Since this is a desirable feature, a |
---|
629 | <TT>driftfile</TT> |
---|
630 | declaration should always be included in the configuration file. |
---|
631 | |
---|
632 | <P>An implication in the above is that, should <TT>ntpd</TT> be stopped |
---|
633 | for some reason, the local platform time will diverge from UTC by an |
---|
634 | amount |
---|
635 | that depends on the intrinsic error of the clock oscillator and the time |
---|
636 | since last synchronized. In view of the length of time necessary to |
---|
637 | refine |
---|
638 | the frequency estimate, every effort should be made to operate the |
---|
639 | daemon |
---|
640 | on a continuous basis and minimize the intervals when for some reason it |
---|
641 | is not running. |
---|
642 | |
---|
643 | <H4> |
---|
644 | Configuring NTP with NetInfo</H4> |
---|
645 | If NetInfo support is compiled into NTP, you can opt to configure ntp |
---|
646 | in your NetInfo domain. NTP will look int he NetInfo directory |
---|
647 | <TT>/locations/ntp</TT> for property/value pairs which are equivalent |
---|
648 | the the lines in the configuration file described above. Each |
---|
649 | configuration keyword may have a coresponding property in NetInfo. |
---|
650 | Each value for a given property is treated as arguments to that property, |
---|
651 | similar to a line in the configuration file. |
---|
652 | |
---|
653 | <P>For example, the configuration shown in the configuration file above |
---|
654 | can be duplicated in NetInfo by adding a property "<TT>server</TT>" with |
---|
655 | values "<TT>rackety.udel.edu</TT>", "<TT>umd1.umd.edu</TT>", and |
---|
656 | "<TT>lilben.tn.cornell.edu</TT>"; and a property "<TT>driftfile</TT>" |
---|
657 | with the single value "<TT>/etc/ntp.drift</TT>". |
---|
658 | |
---|
659 | <P>Values may contain multiple tokens similar to the arguments available |
---|
660 | in the configuration file. For example, to use <TT>mimsy.mil</TT> as an |
---|
661 | NTP version 1 time server, you would add a value "<TT>mimsy.mil version |
---|
662 | 1</TT>" to the "<TT>server</TT>" property. |
---|
663 | |
---|
664 | <H4> |
---|
665 | Ntp4 Versus Previous Versions</H4> |
---|
666 | There are several items of note when dealing with a mixture of |
---|
667 | <TT>ntp4</TT> |
---|
668 | and previous distributions of NTP Version 2 (<TT>ntpd</TT>) and NTP |
---|
669 | Version |
---|
670 | 1 (<TT>ntp3.4</TT>). The <TT>ntp4</TT> implementation conforms to the |
---|
671 | NTP |
---|
672 | Version 3 specification RFC-1305 and, in addition, contains additional |
---|
673 | feaures documented in the <A HREF="release.htm">Release Notes</A> page. |
---|
674 | As such, by default when no additional information is available |
---|
675 | concerning |
---|
676 | the preferences of the peer, <TT>ntpd</TT> claims to be version 4 in the |
---|
677 | packets that it sends from configured associations. The <TT>version |
---|
678 | </TT>subcommand |
---|
679 | of the <TT>server</TT>, <TT>peer</TT>, <TT>broadcast </TT>and |
---|
680 | <TT>manycastclient |
---|
681 | </TT>command can be used to change the default. In unconfigured |
---|
682 | (ephemeral) |
---|
683 | associaitons, the daemon always replies in the same version as the |
---|
684 | request. |
---|
685 | |
---|
686 | <P>An NTP implementation conforming to a previous version specification |
---|
687 | ordinarily discards packets from a later version. However, in most |
---|
688 | respects |
---|
689 | documented in RFC-1305, The version 2 implementation is compatible with |
---|
690 | the version 3 algorithms and protocol. The version 1 implementation |
---|
691 | contains |
---|
692 | most of the version 2 algorithms, but without important features for |
---|
693 | clock |
---|
694 | selection and robustness. Nevertheless, in most respects the NTP |
---|
695 | versions |
---|
696 | are backwards compatible. The sticky part here is that, when a previous |
---|
697 | version implementation receives a packet claiming to be from a version |
---|
698 | 4 server, it discards it without further processing. Hence there is a |
---|
699 | danger |
---|
700 | that in some situations synchronization with previous versions will |
---|
701 | fail. |
---|
702 | |
---|
703 | <P>The trouble occurs when an previous version is to be included in an |
---|
704 | <TT>ntpd</TT> configuration file. With no further indication, |
---|
705 | <TT>ntpd</TT> |
---|
706 | will send packets claiming to be version 4 when it polls. To get around |
---|
707 | this, <TT>ntpd</TT> allows a qualifier to be added to configuration |
---|
708 | entries |
---|
709 | to indicate which version to use when polling. Hence the entries |
---|
710 | <PRE> # specify NTP version 1 |
---|
711 | |
---|
712 | server mimsy.mil version |
---|
713 | 1 # server running ntpd version 1 |
---|
714 | server apple.com version |
---|
715 | 2 # server running ntpd version 2</PRE> |
---|
716 | will cause version 1 packets to be sent to the host mimsy.mil and |
---|
717 | version |
---|
718 | 2 packets to be sent to apple.com. If you are testing <TT>ntpd</TT> |
---|
719 | against |
---|
720 | previous version servers you will need to be careful about this. Note |
---|
721 | that, |
---|
722 | as indicated in the RFC-1305 specification, there is no longer support |
---|
723 | for the original NTP specification, once called NTP Version 0. |
---|
724 | <H4> |
---|
725 | Traffic Monitoring</H4> |
---|
726 | <TT>ntpd</TT> handles peers whose stratum is higher than the stratum of |
---|
727 | the local server and polls using client mode by a fast path which |
---|
728 | minimizes |
---|
729 | the work done in responding to their polls, and normally retains no |
---|
730 | memory |
---|
731 | of these pollers. Sometimes, however, it is interesting to be able to |
---|
732 | determine |
---|
733 | who is polling the server, and how often, as well as who has been |
---|
734 | sending |
---|
735 | other types of queries to the server. |
---|
736 | |
---|
737 | <P>To allow this, <TT>ntpd</TT> implements a traffic monitoring facility |
---|
738 | which records the source address and a minimal amount of other |
---|
739 | information |
---|
740 | from each packet which is received by the server. This feature is |
---|
741 | normally |
---|
742 | enabled, but can be disabled if desired using the configuration file |
---|
743 | entry: |
---|
744 | <PRE> # disable monitoring feature |
---|
745 | disable monitor</PRE> |
---|
746 | The recorded information can be displayed using the <TT>ntpdc</TT> query |
---|
747 | program, described briefly below. |
---|
748 | <H4> |
---|
749 | Address-and-Mask Restrictions</H4> |
---|
750 | The address-and-mask configuration facility supported by <TT>ntpd</TT> |
---|
751 | is quite flexible and general, but is not an integral part of the NTP |
---|
752 | Version |
---|
753 | 3 specification. The major drawback is that, while the internal |
---|
754 | implementation |
---|
755 | is very nice, the user interface is not. For this reason it is probably |
---|
756 | worth doing an example here. Briefly, the facility works as follows. |
---|
757 | There |
---|
758 | is an internal list, each entry of which holds an address, a mask and a |
---|
759 | set of flags. On receipt of a packet, the source address of the packet |
---|
760 | is compared to each entry in the list, with a match being posted when |
---|
761 | the |
---|
762 | following is true: |
---|
763 | <PRE> (source_addr & mask) == (address & |
---|
764 | mask)</PRE> |
---|
765 | A particular source address may match several list entries. In this case |
---|
766 | the entry with the most one bits in the mask is chosen. The flags |
---|
767 | associated |
---|
768 | with this entry are used to control the access. |
---|
769 | |
---|
770 | <P>In the current implementation the flags always add restrictions. In |
---|
771 | effect, an entry with no flags set leaves matching hosts unrestricted. |
---|
772 | An entry can be added to the internal list using a <TT>restrict</TT> |
---|
773 | declaration. |
---|
774 | The flags associated with the entry are specified textually. For |
---|
775 | example, |
---|
776 | the <TT>notrust</TT> flag indicates that hosts matching this entry, |
---|
777 | while |
---|
778 | treated normally in other respects, shouldn't be trusted to provide |
---|
779 | synchronization |
---|
780 | even if otherwise so enabled. The <TT>nomodify</TT> flag indicates that |
---|
781 | hosts matching this entry should not be allowed to do run-time |
---|
782 | configuration. |
---|
783 | There are many more flags, see the <A HREF="ntpd.htm"><TT>ntpd</TT> |
---|
784 | </A>page. |
---|
785 | |
---|
786 | <P>Now the example. Suppose you are running the server on a host whose |
---|
787 | address is 128.100.100.7. You would like to ensure that run time |
---|
788 | reconfiguration |
---|
789 | requests can only be made from the local host and that the server only |
---|
790 | ever synchronizes to one of a pair of off-campus servers or, failing |
---|
791 | that, |
---|
792 | a time source on net 128.100. The following entries in the configuration |
---|
793 | file would implement this policy: |
---|
794 | <PRE> # by default, don't trust and don't allow |
---|
795 | modifications |
---|
796 | |
---|
797 | restrict default notrust nomodify |
---|
798 | |
---|
799 | # these guys are trusted for time, but no |
---|
800 | modifications allowed |
---|
801 | |
---|
802 | restrict 128.100.0.0 mask 255.255.0.0 nomodify |
---|
803 | restrict 128.8.10.1 nomodify |
---|
804 | restrict 192.35.82.50 nomodify |
---|
805 | |
---|
806 | # the local addresses are unrestricted |
---|
807 | |
---|
808 | restrict 128.100.100.7 |
---|
809 | restrict 127.0.0.1</PRE> |
---|
810 | The first entry is the default entry, which all hosts match and hence |
---|
811 | which |
---|
812 | provides the default set of flags. The next three entries indicate that |
---|
813 | matching hosts will only have the <TT>nomodify</TT> flag set and hence |
---|
814 | will be trusted for time. If the mask isn't specified in the |
---|
815 | <TT>restrict</TT> |
---|
816 | keyword, it defaults to 255.255.255.255. Note that the address |
---|
817 | 128.100.100.7 |
---|
818 | matches three entries in the table, the default entry (mask 0.0.0.0), |
---|
819 | the |
---|
820 | entry for net 128.100 (mask 255.255.0.0) and the entry for the host |
---|
821 | itself |
---|
822 | (mask 255.255.255.255). As expected, the flags for the host are derived |
---|
823 | from the last entry since the mask has the most bits set. |
---|
824 | |
---|
825 | <P>The only other thing worth mentioning is that the <TT>restrict</TT> |
---|
826 | declarations apply to packets from all hosts, including those that are |
---|
827 | configured elsewhere in the configuration file and even including your |
---|
828 | clock pseudopeer(s), if any. Hence, if you specify a default set of |
---|
829 | restrictions |
---|
830 | which you don't wish to be applied to your configured peers, you must |
---|
831 | remove |
---|
832 | those restrictions for the configured peers with additional |
---|
833 | <TT>restrict</TT> |
---|
834 | declarations mentioning each peer separately. |
---|
835 | <H4> |
---|
836 | Authentication</H4> |
---|
837 | <TT>ntpd</TT> supports the optional authentication procedure specified |
---|
838 | in the NTP Version 2 and 3 specifications. Briefly, when an association |
---|
839 | runs in authenticated mode, each packet transmitted has appended to it |
---|
840 | a 32-bit key ID and a 64/128-bit cryptographic checksum of the packet |
---|
841 | contents |
---|
842 | computed using either the Data Encryption Standard (DES) or Message |
---|
843 | Digest |
---|
844 | (MD5) algorithms. Note that, while either of these algorithms provide |
---|
845 | sufficient |
---|
846 | protection from message- modification attacks, distribution of the |
---|
847 | former |
---|
848 | algorithm implementation is restricted to the U.S. and Canada, while the |
---|
849 | latter presently is free from such restrictions. For this reason, the |
---|
850 | DES |
---|
851 | algorithm is not included in the current distribution. Directions for |
---|
852 | obtaining |
---|
853 | it in other countries is in the <A HREF="build.htm">Building and |
---|
854 | Installing |
---|
855 | the Distribution</A> page. With either algorithm the receiving peer |
---|
856 | recomputes |
---|
857 | the checksum and compares it with the one included in the packet. For |
---|
858 | this |
---|
859 | to work, the peers must share at least one encryption key and, |
---|
860 | furthermore, |
---|
861 | must associate the shared key with the same key ID. |
---|
862 | |
---|
863 | <P>This facility requires some minor modifications to the basic packet |
---|
864 | processing procedures, as required by the specification. These |
---|
865 | modifications |
---|
866 | are enabled by the <TT>enable auth</TT> configuration declaration, which |
---|
867 | is currently the default. In authenticated mode, peers which send |
---|
868 | unauthenticated |
---|
869 | packets, peers which send authenticated packets which the local server |
---|
870 | is unable to decrypt and peers which send authenticated packets |
---|
871 | encrypted |
---|
872 | using a key we don't trust are all marked untrustworthy and unsuitable |
---|
873 | for synchronization. Note that, while the server may know many keys |
---|
874 | (identified |
---|
875 | by many key IDs), it is possible to declare only a subset of these as |
---|
876 | trusted. |
---|
877 | This allows the server to share keys with a client which requires |
---|
878 | authenticated |
---|
879 | time and which trusts the server, but which is not trusted by the |
---|
880 | server. |
---|
881 | Also, some additional configuration language is required to specify the |
---|
882 | key ID to be used to authenticate each configured peer association. |
---|
883 | Hence, |
---|
884 | for a server running in authenticated mode, the configuration file might |
---|
885 | look similar to the following: |
---|
886 | <PRE> # peer configuration for 128.100.100.7 |
---|
887 | # (expected to operate at stratum 2) |
---|
888 | # fully authenticated this time |
---|
889 | |
---|
890 | peer 128.100.49.105 key 22 # |
---|
891 | suzuki.ccie.utoronto.ca |
---|
892 | peer 128.8.10.1 key 4 # |
---|
893 | umd1.umd.edu |
---|
894 | peer 192.35.82.50 key 6 # |
---|
895 | lilben.tn.cornell.edu |
---|
896 | |
---|
897 | keys /usr/local/etc/ntp.keys # path for |
---|
898 | key file |
---|
899 | trustedkey 1 2 14 15 # |
---|
900 | define trusted keys |
---|
901 | requestkey |
---|
902 | 15 # |
---|
903 | key (7) for accessing server variables |
---|
904 | controlkey |
---|
905 | 15 # |
---|
906 | key (6) for accessing server variables |
---|
907 | |
---|
908 | authdelay |
---|
909 | 0.000094 # authentication delay |
---|
910 | (Sun4c/50 IPX)</PRE> |
---|
911 | There are a couple of previously unmentioned things in here. The |
---|
912 | <TT>keys |
---|
913 | </TT>line specifies the path to the keys file (see below and the |
---|
914 | <TT>ntpd</TT> |
---|
915 | document page for details of the file format). The <TT>trustedkey</TT> |
---|
916 | declaration identifies those keys that are known to be uncompromised; |
---|
917 | the |
---|
918 | remainder presumably represent the expired or possibly compromised keys. |
---|
919 | Both sets of keys must be declared by key identifier in the |
---|
920 | <TT>ntp.keys</TT> |
---|
921 | file described below. This provides a way to retire old keys while |
---|
922 | minimizing |
---|
923 | the frequency of delicate key-distribution procedures. The |
---|
924 | <TT>requestkey</TT> |
---|
925 | line establishes the key to be used for mode-6 control messages as |
---|
926 | specified |
---|
927 | in RFC-1305 and used by the <TT>ntpq</TT> utility program, while the |
---|
928 | <TT>controlkey |
---|
929 | </TT>line establishes the key to be used for mode-7 private control |
---|
930 | messages |
---|
931 | used by the <TT>ntpdc</TT> utility program. These keys are used to |
---|
932 | prevent |
---|
933 | unauthorized modification of daemon variables. |
---|
934 | |
---|
935 | <P>Ordinarily, the authentication delay; that is, the processing time |
---|
936 | taken |
---|
937 | between the freezing of a transmit timestamp and the actual transmission |
---|
938 | of the packet when authentication is enabled (i.e. more or less the time |
---|
939 | it takes for the DES or MD5 routine to encrypt a single block) is |
---|
940 | computed |
---|
941 | automatically by the daemon. If necessary, the delay can be overriden by |
---|
942 | the <TT>authdelay </TT>line, which is used as a correction for the |
---|
943 | transmit |
---|
944 | timestamp. This can be computed for your CPU by the <A |
---|
945 | HREF="authspeed.htm"><TT>authspeed</TT> |
---|
946 | </A>program included in the distribution. The usage is illustrated by |
---|
947 | the |
---|
948 | following: |
---|
949 | <PRE> # for DES keys |
---|
950 | |
---|
951 | authspeed -n 30000 auth.samplekeys |
---|
952 | # for MD5 keys |
---|
953 | |
---|
954 | authspeed -mn 30000 auth.samplekeys</PRE> |
---|
955 | Additional utility programs included in the <TT>./authstuff</TT> |
---|
956 | directory |
---|
957 | can be used to generate random keys, certify implementation correctness |
---|
958 | and display sample keys. As a general rule, keys should be chosen |
---|
959 | randomly, |
---|
960 | except possibly the request and control keys, which must be entered by |
---|
961 | the user as a password. |
---|
962 | |
---|
963 | <P>The <TT>ntp.keys</TT> file contains the list of keys and associated |
---|
964 | key IDs the server knows about (for obvious reasons this file is better |
---|
965 | left unreadable by anyone except root). The contents of this file might |
---|
966 | look like: |
---|
967 | <PRE> # ntp keys file (ntp.keys) |
---|
968 | 1 N |
---|
969 | 29233E0461ECD6AE # des key in NTP format |
---|
970 | 2 M |
---|
971 | RIrop8KPPvQvYotM # md5 key as an ASCII random string |
---|
972 | 14 M |
---|
973 | sundial   |
---|
974 | ; # md5 key as an ASCII string |
---|
975 | 15 A |
---|
976 | sundial   |
---|
977 | ; # des key as an ASCII string |
---|
978 | |
---|
979 | # the following 3 keys are identical |
---|
980 | |
---|
981 | 10 A SeCReT |
---|
982 | 10 N |
---|
983 | d3e54352e5548080 |
---|
984 | 10 S |
---|
985 | a7cb86a4cba80101</PRE> |
---|
986 | In the keys file the first token on each line indicates the key ID, the |
---|
987 | second token the format of the key and the third the key itself. There |
---|
988 | are four key formats. An <TT>A</TT> indicates a DES key written as a 1- |
---|
989 | to-8 |
---|
990 | character string in 7-bit ASCII representation, with each character |
---|
991 | standing |
---|
992 | for a key octet (like a Unix password). An <TT>S</TT> indicates a DES |
---|
993 | key |
---|
994 | written as a hex number in the DES standard format, with the low order |
---|
995 | bit (LSB) of each octet being the (odd) parity bit. An <TT>N</TT> |
---|
996 | indicates |
---|
997 | a DES key again written as a hex number, but in NTP standard format with |
---|
998 | the high order bit of each octet being the (odd) parity bit (confusing |
---|
999 | enough?). An <TT>M</TT> indicates an MD5 key written as a 1-to-31 |
---|
1000 | character |
---|
1001 | ASCII string in the <TT>A</TT> format. Note that, because of the simple |
---|
1002 | tokenizing routine, the characters <TT>' ', '#', '\t', '\n'</TT> and |
---|
1003 | <TT>'\0'</TT> |
---|
1004 | can't be used in either a DES or MD5 ASCII key. Everything else is fair |
---|
1005 | game, though. Key 0 (zero) is used for special purposes and should not |
---|
1006 | appear in this file. |
---|
1007 | |
---|
1008 | <P>The big trouble with the authentication facility is the keys file. It |
---|
1009 | is a maintenance headache and a security problem. This should be fixed |
---|
1010 | some day. Presumably, this whole bag of worms goes away if/when a |
---|
1011 | generic |
---|
1012 | security regime for the Internet is established. An alternative with NTP |
---|
1013 | Version 4 is the autokey feature, which uses random session keys and |
---|
1014 | public-key |
---|
1015 | cruptography and avoids the key file entirely. While this feature is not |
---|
1016 | completely finished yet, details can be found in the <A |
---|
1017 | HREF="release.htm">Release |
---|
1018 | Notes</A> page. |
---|
1019 | <H4> |
---|
1020 | Query Programs</H4> |
---|
1021 | Three utility query programs are included with the distribution, |
---|
1022 | <TT>ntpq</TT>, |
---|
1023 | <TT>ntptrace</TT> and <TT>ntpdc</TT>. <TT>ntpq</TT> is a handy program |
---|
1024 | which sends queries and receives responses using NTP standard mode-6 |
---|
1025 | control |
---|
1026 | messages. Since it uses the standard control protocol specified in RFC- |
---|
1027 | 1305, |
---|
1028 | it may be used with NTP Version 2 and Version 3 implementations for both |
---|
1029 | Unix and Fuzzball, but not Version 1 implementations. It is most useful |
---|
1030 | to query remote NTP implementations to assess timekeeping accuracy and |
---|
1031 | expose bugs in configuration or operation. |
---|
1032 | |
---|
1033 | <P><TT>ntptrace</TT> can be used to display the current synchronization |
---|
1034 | path from a selected host through possibly intervening servers to the |
---|
1035 | primary |
---|
1036 | source of synchronization, usually a radio clock. It works with both |
---|
1037 | version |
---|
1038 | 2 and version 3 servers, but not version 1. |
---|
1039 | |
---|
1040 | <P><TT>ntpdc</TT> is a horrid program which uses NTP private mode-7 |
---|
1041 | control |
---|
1042 | messages to query local or remote servers. The format and contents of |
---|
1043 | these |
---|
1044 | messages are specific to this version of <TT>ntpd</TT> and some older |
---|
1045 | versions. |
---|
1046 | The program does allow inspection of a wide variety of internal counters |
---|
1047 | and other state data, and hence does make a pretty good debugging tool, |
---|
1048 | even if it is frustrating to use. The other thing of note about |
---|
1049 | <TT>ntpdc</TT> |
---|
1050 | is that it provides a user interface to the run time reconfiguration |
---|
1051 | facility. |
---|
1052 | See the respective document pages for details on the use of these |
---|
1053 | programs. |
---|
1054 | <H4> |
---|
1055 | Run-Time Reconfiguration</H4> |
---|
1056 | <TT>ntpd</TT> was written specifically to allow its configuration to be |
---|
1057 | fully modifiable at run time. Indeed, the only way to configure the |
---|
1058 | server |
---|
1059 | is at run time. The configuration file is read only after the rest of |
---|
1060 | the |
---|
1061 | server has been initialized into a running default-configured state. |
---|
1062 | This |
---|
1063 | facility was included not so much for the benefit of Unix, where it is |
---|
1064 | handy but not strictly essential, but rather for dedicated platforms |
---|
1065 | where |
---|
1066 | the feature is more important for maintenance. Nevertheless, run time |
---|
1067 | configuration |
---|
1068 | works very nicely for Unix servers as well. |
---|
1069 | |
---|
1070 | <P>Nearly all of the things it is possible to configure in the |
---|
1071 | configuration |
---|
1072 | file may be altered via NTP mode-7 messages using the <TT>ntpdc</TT> |
---|
1073 | program. |
---|
1074 | Mode-6 messages may also provide some limited configuration |
---|
1075 | functionality |
---|
1076 | (though the only thing you can currently do with mode-6 messages is set |
---|
1077 | the leap-second warning bits) and the <TT>ntpq</TT> program provides |
---|
1078 | generic |
---|
1079 | support for the latter. The leap bits that can be set in the |
---|
1080 | <TT>leap_warning</TT> |
---|
1081 | variable (up to one month ahead) and in the <TT>leap_indication</TT> |
---|
1082 | variable |
---|
1083 | have a slightly different encoding than the usual interpretation: |
---|
1084 | <PRE> |
---|
1085 | Value Action |
---|
1086 | |
---|
1087 | |
---|
1088 | 00 &nbs |
---|
1089 | p; The daemon passes the leap bits of its |
---|
1090 | |
---|
1091 | |
---|
1092 | synchronisation source (usual mode of operation) |
---|
1093 | |
---|
1094 | 01/10 A leap |
---|
1095 | second is added/deleted |
---|
1096 | |
---|
1097 | |
---|
1098 | 11 &nbs |
---|
1099 | p; Leap information from the synchronization source |
---|
1100 | |
---|
1101 | is |
---|
1102 | ignored (thus LEAP_NOWARNING is passed on)</PRE> |
---|
1103 | Mode-6 and mode-7 messages which would modify the configuration of the |
---|
1104 | server are required to be authenticated using standard NTP |
---|
1105 | authentication. |
---|
1106 | To enable the facilities one must, in addition to specifying the |
---|
1107 | location |
---|
1108 | of a keys file, indicate in the configuration file the key IDs to be |
---|
1109 | used |
---|
1110 | for authenticating reconfiguration commands. Hence the following |
---|
1111 | fragment |
---|
1112 | might be added to a configuration file to enable the mode-6 (ntpq) and |
---|
1113 | mode-7 (ntpdc) facilities in the daemon: |
---|
1114 | <PRE> # specify mode-6 and mode-7 trusted keys |
---|
1115 | |
---|
1116 | requestkey 65535 # for mode-7 |
---|
1117 | requests |
---|
1118 | controlkey 65534 # for mode-6 |
---|
1119 | requests</PRE> |
---|
1120 | If the <TT>requestkey</TT> and/or the <TT>controlkey</TT> configuration |
---|
1121 | declarations are omitted from the configuration file, the corresponding |
---|
1122 | run-time reconfiguration facility is disabled. |
---|
1123 | |
---|
1124 | <P>The query programs require the user to specify a key ID and a key to |
---|
1125 | use for authenticating requests to be sent. The key ID provided should |
---|
1126 | be the same as the one mentioned in the configuration file, while the |
---|
1127 | key |
---|
1128 | should match that corresponding to the key ID in the keys file. As the |
---|
1129 | query programs prompt for the key as a password, it is useful to make |
---|
1130 | the |
---|
1131 | request and control authentication keys typeable (in ASCII format) from |
---|
1132 | the keyboard. |
---|
1133 | <H4> |
---|
1134 | Name Resolution</H4> |
---|
1135 | <TT>ntpd</TT> includes the capability to specify host names requiring |
---|
1136 | resolution |
---|
1137 | in <TT>peer</TT> and <TT>server</TT> declarations in the configuration |
---|
1138 | file. However, in some outposts of the Internet, name resolution is |
---|
1139 | unreliable |
---|
1140 | and the interface to the Unix resolver routines is synchronous. The |
---|
1141 | hangups |
---|
1142 | and delays resulting from name-resolver clanking can be unacceptable |
---|
1143 | once |
---|
1144 | the NTP server is running (and remember it is up and running before the |
---|
1145 | configuration file is read). However, it is advantageous to resolve time |
---|
1146 | server names, since their addresses are occasionally changed. |
---|
1147 | |
---|
1148 | <P>In order to prevent configuration delays due to the name resolver, |
---|
1149 | the |
---|
1150 | daemon runs the name resolution process in parallel with the main daemon |
---|
1151 | code. When the daemon comes across a <TT>peer</TT> or <TT>server</TT> |
---|
1152 | entry |
---|
1153 | with a non-numeric host address, it records the relevant information in |
---|
1154 | a temporary file and continues on. When the end of the configuration |
---|
1155 | file |
---|
1156 | has been reached and one or more entries requiring name resolution have |
---|
1157 | been found, the server runs the name resolver from the temporary file. |
---|
1158 | The server then continues on normally but with the offending |
---|
1159 | peers/servers |
---|
1160 | omitted from its configuration. |
---|
1161 | |
---|
1162 | <P>As each name is resolved, it configures the associated entry into the |
---|
1163 | server using the same mode-7 run time reconfiguration facility that |
---|
1164 | <TT>ntpdc</TT> |
---|
1165 | uses. If temporary resolver failures occur, the resolver will |
---|
1166 | periodically |
---|
1167 | retry the requests until a definite response is received. The program |
---|
1168 | will |
---|
1169 | continue to run until all entries have been resolved. |
---|
1170 | <H4> |
---|
1171 | <A NAME="frequency_tolerance">Dealing with Frequency Tolerance |
---|
1172 | Violations</A> |
---|
1173 | (<TT>tickadj</TT> and Friends)</H4> |
---|
1174 | The NTP Version 3 specification RFC-1305 calls for a maximum oscillator |
---|
1175 | frequency tolerance of +-100 parts-per-million (PPM), which is |
---|
1176 | representative |
---|
1177 | of those components suitable for use in relatively inexpensive |
---|
1178 | workstation |
---|
1179 | platforms. For those platforms meeting this tolerance, NTP will |
---|
1180 | automatically |
---|
1181 | compensate for the frequency errors of the individual oscillator and no |
---|
1182 | further adjustments are required, either to the configuration file or to |
---|
1183 | various kernel variables. For the NTP Version 4 release, this tolerance |
---|
1184 | has been increased to +-500 PPM. |
---|
1185 | |
---|
1186 | <P>However, in the case of certain notorious platforms, in particular |
---|
1187 | Sun |
---|
1188 | 4.1.1 systems, the performance can be improved by adjusting the values |
---|
1189 | of certain kernel variables; in particular, <TT>tick</TT> and |
---|
1190 | <TT>tickadj</TT>. |
---|
1191 | The variable <TT>tick</TT> is the increment in microseconds added to the |
---|
1192 | system time on each interval- timer interrupt, while the variable |
---|
1193 | <TT>tickadj</TT> |
---|
1194 | is used by the time adjustment code as a slew rate, in microseconds per |
---|
1195 | tick. When the time is being adjusted via a call to the system routine |
---|
1196 | <TT>adjtime()</TT>, the kernel increases or reduces tick by |
---|
1197 | <TT>tickadj</TT> |
---|
1198 | microseconds per tick until the specified adjustment has been completed. |
---|
1199 | Unfortunately, in most Unix implementations the tick increment must be |
---|
1200 | either zero or plus/minus exactly <TT>tickadj</TT> microseconds, meaning |
---|
1201 | that adjustments are truncated to be an integral multiple of |
---|
1202 | <TT>tickadj</TT> |
---|
1203 | (this latter behaviour is a misfeature, and is the only reason the |
---|
1204 | <TT>tickadj</TT> |
---|
1205 | code needs to concern itself with the internal implementation of |
---|
1206 | <TT>tickadj</TT> |
---|
1207 | at all). In addition, the stock Unix implementation considers it an |
---|
1208 | error |
---|
1209 | to request another adjustment before a prior one has completed. |
---|
1210 | <P>Thus, to make very sure it avoids problems related to the roundoff, |
---|
1211 | the <TT>tickadj </TT>program can be used to adjust the values of |
---|
1212 | <TT>tick</TT> |
---|
1213 | and <TT>tickadj</TT>. This ensures that all adjustments given to |
---|
1214 | <TT>adjtime()</TT> |
---|
1215 | are an even multiple of <TT>tickadj</TT> microseconds and computes the |
---|
1216 | largest adjustment that can be completed in the adjustment interval |
---|
1217 | (using |
---|
1218 | both the value of <TT>tick</TT> and the value of <TT>tickadj</TT>) so it |
---|
1219 | can avoid exceeding this limit. It is important to note that not all |
---|
1220 | systems |
---|
1221 | will allow inspection or modification of kernel variables other than at |
---|
1222 | system build time. It is also important to know that, with the current |
---|
1223 | NTP tolerances, it is rarely necessary to make these changes, but in |
---|
1224 | many |
---|
1225 | cases they will substantially improve the general accurace of the time |
---|
1226 | service. |
---|
1227 | |
---|
1228 | <P>Unfortunately, the value of <TT>tickadj</TT> set by default is almost |
---|
1229 | always too large for <TT>ntpd</TT>. NTP operates by continuously making |
---|
1230 | small adjustments to the clock, usually at one-second intervals. If |
---|
1231 | <TT>tickadj</TT> |
---|
1232 | is set too large, the adjustments will disappear in the roundoff; while, |
---|
1233 | if <TT>tickadj</TT> is too small, NTP will have difficulty if it needs |
---|
1234 | to make an occasional large adjustment. While the daemon itself will |
---|
1235 | read |
---|
1236 | the kernel's values of these variables, it will not change the values, |
---|
1237 | even if they are unsuitable. You must do this yourself before the daemon |
---|
1238 | is started using the <TT>tickadj</TT> program included in the |
---|
1239 | <TT>./util</TT> |
---|
1240 | directory of the distribution. Note that the latter program will also |
---|
1241 | compute |
---|
1242 | an optimal value of <TT>tickadj</TT> for NTP use based on the kernel's |
---|
1243 | value of <TT>tick</TT>. |
---|
1244 | |
---|
1245 | <P>The <TT>tickadj</TT> program can reset several other kernel variables |
---|
1246 | if asked. It can change the value of <TT>tick</TT> if asked. This is |
---|
1247 | handy to compensate for kernel bugs which cause the clock to run with a |
---|
1248 | very large frequency error, as with SunOS 4.1.1 systems. It can also be |
---|
1249 | used to set the value of the kernel <TT>dosynctodr</TT> variable to |
---|
1250 | zero. This variable controls whether to synchronize the system clock to |
---|
1251 | the time-of-day clock, something you really don't want to be happen |
---|
1252 | when <TT>ntpd</TT> is trying to keep it under control. In some systems, |
---|
1253 | such as recent Sun Solaris kernels, the <TT>dosynctodr </TT>variable is |
---|
1254 | the only one that can be changed by the <TT>tickadj </TT>program. In |
---|
1255 | this and other modern kernels, it is not necessary to change the other |
---|
1256 | variables in any case. |
---|
1257 | |
---|
1258 | <P> |
---|
1259 | We have a report that says starting with Solaris 2.6 we should |
---|
1260 | leave <I>dosynctodr</I> alone. |
---|
1261 | <A HREF="solaris-dosynctodr.html">Here is the report</A>. |
---|
1262 | |
---|
1263 | <P>In order to maintain reasonable correctness bounds, as well as |
---|
1264 | reasonably |
---|
1265 | good accuracy with acceptable polling intervals, <TT>ntpd</TT> will |
---|
1266 | complain |
---|
1267 | if the frequency error is greater than 500 PPM. For machines with a |
---|
1268 | value |
---|
1269 | of <TT>tick</TT> in the 10-ms range, a change of one in the value of |
---|
1270 | <TT>tick</TT> |
---|
1271 | will change the frequency by about 100 PPM. In order to determine the |
---|
1272 | value |
---|
1273 | of <TT>tick</TT> for a particular CPU, disconnect the machine from all |
---|
1274 | sources of time (<TT>dosynctodr</TT> = 0) and record its actual time |
---|
1275 | compared |
---|
1276 | to an outside source (eyeball-and-wristwatch will do) over a day or |
---|
1277 | more. |
---|
1278 | Multiply the time change over the day by 0.116 and add or subtract the |
---|
1279 | result to tick, depending on whether the CPU is fast or slow. An example |
---|
1280 | call to <TT>tickadj</TT> useful on SunOS 4.1.1 is: |
---|
1281 | <PRE> <TT>tickadj</TT> -t 9999 -a 5 -s</PRE> |
---|
1282 | which sets tick 100 PPM fast, <TT>tickadj</TT> to 5 microseconds and |
---|
1283 | turns |
---|
1284 | off the clock/calendar chip fiddle. This line can be added to the |
---|
1285 | <TT>rc.local</TT> |
---|
1286 | configuration file to automatically set the kernel variables at boot |
---|
1287 | time. |
---|
1288 | |
---|
1289 | <P>All this stuff about diddling kernel variables so the NTP daemon will |
---|
1290 | work is really silly. If vendors would ship machines with clocks that |
---|
1291 | kept |
---|
1292 | reasonable time and would make their <TT>adjtime()</TT> system call |
---|
1293 | apply |
---|
1294 | the slew it is given exactly, independent of the value of |
---|
1295 | <TT>tickadj</TT>, |
---|
1296 | all this could go away. This is in fact the case on many current Unix |
---|
1297 | systems. |
---|
1298 | <H4> |
---|
1299 | Tuning Your Subnet</H4> |
---|
1300 | There are several parameters available for tuning the NTP subnet for |
---|
1301 | maximum |
---|
1302 | accuracy and minimum jitter. One of these is the <TT>prefer</TT> |
---|
1303 | configuration |
---|
1304 | declaration described in <A HREF="prefer.htm">Mitigation Rules and the |
---|
1305 | <TT>prefer</TT> Keyword </A>documentation page. When more than one |
---|
1306 | eligible |
---|
1307 | server exists, the NTP clock-selection and combining algorithms act to |
---|
1308 | winnow out all except the "best" set of servers using several criteria |
---|
1309 | based on differences between the readings of different servers and |
---|
1310 | between |
---|
1311 | successive readings of the same server. The result is usually a set of |
---|
1312 | surviving servers that are apparently statistically equivalent in |
---|
1313 | accuracy, |
---|
1314 | jitter and stability. The population of survivors remaining in this set |
---|
1315 | depends on the individual server characteristics measured during the |
---|
1316 | selection |
---|
1317 | process and may vary from time to time as the result of normal |
---|
1318 | statistical |
---|
1319 | variations. In LANs with high speed RISC-based time servers, the |
---|
1320 | population |
---|
1321 | can become somewhat unstable, with individual servers popping in and out |
---|
1322 | of the surviving population, generally resulting in a regime called |
---|
1323 | <I>clockhopping</I>. |
---|
1324 | |
---|
1325 | <P>When only the smallest residual jitter can be tolerated, it may be |
---|
1326 | convenient |
---|
1327 | to elect one of the servers at each stratum level as the preferred one |
---|
1328 | using the keyword <TT>prefer</TT> on the configuration declaration for |
---|
1329 | the selected server: |
---|
1330 | <PRE> # preferred server declaration |
---|
1331 | |
---|
1332 | peer rackety.udel.edu prefer |
---|
1333 | # preferred server</PRE> |
---|
1334 | The preferred server will always be included in the surviving |
---|
1335 | population, |
---|
1336 | regardless of its characteristics and as long as it survives preliminary |
---|
1337 | sanity checks and validation procedures. |
---|
1338 | |
---|
1339 | <P>The most useful application of the <TT>prefer</TT> keyword is in high |
---|
1340 | speed LANs equipped with precision radio clocks, such as a GPS receiver. |
---|
1341 | In order to insure robustness, the hosts need to include outside peers |
---|
1342 | as well as the GPS-equipped server; however, as long as that server is |
---|
1343 | running, the synchronization preference should be that server. The |
---|
1344 | keyword |
---|
1345 | should normally be used in all cases in order to prefer an attached |
---|
1346 | radio |
---|
1347 | clock. It is probably inadvisable to use this keyword for peers outside |
---|
1348 | the LAN, since it interferes with the carefully crafted judgement of the |
---|
1349 | selection and combining algorithms. |
---|
1350 | <H4> |
---|
1351 | Provisions for Leap Seconds and Accuracy Metrics</H4> |
---|
1352 | <TT>ntpd</TT> understands leap seconds and will attempt to take |
---|
1353 | appropriate |
---|
1354 | action when one occurs. In principle, every host running ntpd will |
---|
1355 | insert |
---|
1356 | a leap second in the local timescale in precise synchronization with |
---|
1357 | UTC. |
---|
1358 | This requires that the leap-warning bits be activated some time prior to |
---|
1359 | the occurrence of a leap second at the primary (stratum 1) servers. |
---|
1360 | Subsequently, |
---|
1361 | these bits are propagated throughout the subnet depending on these |
---|
1362 | servers |
---|
1363 | by the NTP protocol itself and automatically implemented by |
---|
1364 | <TT>ntpd</TT> |
---|
1365 | and the time- conversion routines of each host. The implementation is |
---|
1366 | independent |
---|
1367 | of the idiosyncrasies of the particular radio clock, which vary widely |
---|
1368 | among the various devices, as long as the idiosyncratic behavior does |
---|
1369 | not |
---|
1370 | last for more than about 20 minutes following the leap. Provisions are |
---|
1371 | included to modify the behavior in cases where this cannot be |
---|
1372 | guaranteed. |
---|
1373 | While provisions for leap seconds have been carefully crafted so that |
---|
1374 | correct |
---|
1375 | timekeeping immediately before, during and after the occurrence of a |
---|
1376 | leap |
---|
1377 | second is scrupulously correct, stock Unix systems are mostly inept in |
---|
1378 | responding to the available information. This caveat goes also for the |
---|
1379 | maximum-error and statistical-error bounds carefully calculated for all |
---|
1380 | clients and servers, which could be very useful for application programs |
---|
1381 | needing to calibrate the delays and offsets to achieve a near- |
---|
1382 | simultaneous |
---|
1383 | commit procedure, for example. While this information is maintained in |
---|
1384 | the <TT>ntpd</TT> data structures, there is at present no way for |
---|
1385 | application |
---|
1386 | programs to access it. This may be a topic for further development. |
---|
1387 | <H4> |
---|
1388 | Clock Support Overview</H4> |
---|
1389 | <TT>ntpd</TT> was designed to support radio (and other external) clocks |
---|
1390 | and does some parts of this function with utmost care. Clocks are |
---|
1391 | treated |
---|
1392 | by the protocol as ordinary NTP peers, even to the point of referring to |
---|
1393 | them with an (invalid) IP host address. Clock addresses are of the form |
---|
1394 | 127.127.<I>t.u</I>, where <I>t</I> specifies the particular type of |
---|
1395 | clock |
---|
1396 | (i.e., refers to a particular clock driver) and <I>u</I> is a unit |
---|
1397 | number |
---|
1398 | whose interpretation is clock-driver dependent. This is analogous to the |
---|
1399 | use of major and minor device numbers by Unix and permits multiple |
---|
1400 | instantiations |
---|
1401 | of clocks of the same type on the same server, should such magnificent |
---|
1402 | redundancy be required. |
---|
1403 | |
---|
1404 | <P>Because clocks look much like peers, both configuration file syntax |
---|
1405 | and run time reconfiguration commands can be used to control clocks in |
---|
1406 | the same way as ordinary peers. Clocks are configured via |
---|
1407 | <TT>server</TT> |
---|
1408 | declarations in the configuration file, can be started and stopped using |
---|
1409 | ntpdc and are subject to address-and-mask restrictions much like a |
---|
1410 | normal |
---|
1411 | peer, should this stretch of imagination ever be useful. As a concession |
---|
1412 | to the need to sometimes transmit additional information to clock |
---|
1413 | drivers, |
---|
1414 | an additional configuration file is available: the <TT>fudge</TT> |
---|
1415 | statement. |
---|
1416 | This enables one to specify the values of two time quantities, two |
---|
1417 | integral |
---|
1418 | values and two flags, the use of which is dependent on the particular |
---|
1419 | clock |
---|
1420 | driver. For example, to configure a PST radio clock which can be |
---|
1421 | accessed |
---|
1422 | through the serial device <TT>/dev/pst1</TT>, with propagation delays to |
---|
1423 | WWV and WWVH of 7.5 and 26.5 milliseconds, respectively, on a machine |
---|
1424 | with |
---|
1425 | an imprecise system clock and with the driver set to disbelieve the |
---|
1426 | radio |
---|
1427 | clock once it has gone 30 minutes without an update, one might use the |
---|
1428 | following configuration file entries: |
---|
1429 | <PRE> # radio clock fudge fiddles |
---|
1430 | server 127.127.3.1 |
---|
1431 | fudge 127.127.3.1 time1 0.0075 time2 0.0265 |
---|
1432 | fudge 127.127.3.1 value2 30 flag1 1</PRE> |
---|
1433 | Additional information on the interpretation of these data with respect |
---|
1434 | to various radio clock drivers is given in the <A |
---|
1435 | HREF="refclock.htm">Reference |
---|
1436 | Clock Drivers </A>document page and in the individual driver documents |
---|
1437 | accessible via that page. |
---|
1438 | <H4> |
---|
1439 | Towards the Ultimate Tick</H4> |
---|
1440 | This section considers issues in providing precision time |
---|
1441 | synchronization |
---|
1442 | in NTP subnets which need the highest quality time available in the |
---|
1443 | present |
---|
1444 | technology. These issues are important in subnets supporting real-time |
---|
1445 | services such as distributed multimedia conferencing and wide-area |
---|
1446 | experiment |
---|
1447 | control and monitoring. |
---|
1448 | |
---|
1449 | <P>In the Internet of today synchronization paths often span continents |
---|
1450 | and oceans with moderate to high variations in delay due to traffic |
---|
1451 | spasms. |
---|
1452 | NTP is specifically designed to minimize timekeeping jitter due to delay |
---|
1453 | variations using intricately crafted filtering and selection algorithms; |
---|
1454 | however, in cases where these variations are as much as a second or |
---|
1455 | more, |
---|
1456 | the residual jitter following these algorithms may still be excessive. |
---|
1457 | Sometimes, as in the case of some isolated NTP subnets where a local |
---|
1458 | source |
---|
1459 | of precision time is available, such as a PPS signal produced by a |
---|
1460 | calibrated |
---|
1461 | cesium clock, it is possible to remove the jitter and retime the local |
---|
1462 | clock oscillator of the NTP server. This has turned out to be a useful |
---|
1463 | feature to improve the synchronization quality of time distributed in |
---|
1464 | remote |
---|
1465 | places where radio clocks are not available. In these cases special |
---|
1466 | features |
---|
1467 | of the distribution are used together with the PPS signal to provide a |
---|
1468 | jitter-free timing signal, while NTP itself is used to provide the |
---|
1469 | coarse |
---|
1470 | timing and resolve the seconds numbering. |
---|
1471 | |
---|
1472 | <P>Most available radio clocks can provide time to an accuracy in the |
---|
1473 | order |
---|
1474 | of milliseconds, depending on propagation conditions, local noise levels |
---|
1475 | and so forth. However, as a practical matter, all clocks can |
---|
1476 | occasionally |
---|
1477 | display errors significantly exceeding nominal specifications. Usually, |
---|
1478 | the algorithms used by NTP for ordinary network peers, as well as radio |
---|
1479 | clock peers will detect and discard these errors as discrepancies |
---|
1480 | between |
---|
1481 | the disciplined local clock oscillator and the decoded time message |
---|
1482 | produced |
---|
1483 | by the radio clock. Some radio clocks can produce a special PPS signal |
---|
1484 | which can be interfaced to the server platform in a number of ways and |
---|
1485 | used to substantially improve the (disciplined) clock oscillator jitter |
---|
1486 | and wander characteristics by at least an order of magnitude. Using |
---|
1487 | these |
---|
1488 | features it is possible to achieve accuracies in the order of a few tens |
---|
1489 | of microseconds with a fast RISC- based platform. |
---|
1490 | |
---|
1491 | <P>There are three ways to implement PPS support, depending on the radio |
---|
1492 | clock model, platform model and serial line interface. These are |
---|
1493 | described |
---|
1494 | in detail in the application notes mentioned in the <A |
---|
1495 | HREF="index.htm">The |
---|
1496 | Network Time Protocol (NTP) Distribution </A>document page. Each of |
---|
1497 | these |
---|
1498 | requires circuitry to convert the TTL signal produced by most clocks to |
---|
1499 | the EIA levels used by most serial interfaces. The <A |
---|
1500 | HREF="gadget.htm">Gadget |
---|
1501 | Box PPS Level Converter and CHU Modem </A>document page describes a |
---|
1502 | device |
---|
1503 | designed to do this. Besides being useful for this purpose, this device |
---|
1504 | includes an inexpensive modem designed for use with the Canadian CHU |
---|
1505 | time/frequency |
---|
1506 | radio station. |
---|
1507 | |
---|
1508 | <P>In order to select the appropriate implementation, it is important to |
---|
1509 | understand the underlying PPS mechanism used by ntpd. The PPS support |
---|
1510 | depends |
---|
1511 | on a continuous source of PPS pulses used to calculate an offset within |
---|
1512 | +-500 milliseconds relative to the local clock. The serial timecode |
---|
1513 | produced |
---|
1514 | by the radio or the time determined by NTP in absence of the radio is |
---|
1515 | used |
---|
1516 | to adjust the local clock within +-128 milliseconds of the actual time. |
---|
1517 | As long as the local clock is within this interval the PPS support is |
---|
1518 | used |
---|
1519 | to discipline the local clock and the timecode used only to verify that |
---|
1520 | the local clock is in fact within the interval. Outside this interval |
---|
1521 | the |
---|
1522 | PPS support is disabled and the timecode used directly to control the |
---|
1523 | local |
---|
1524 | clock. |
---|
1525 | <H4> |
---|
1526 | Parting Shots</H4> |
---|
1527 | There are several undocumented programs which can be useful in unusual |
---|
1528 | cases. They can be found in the <TT>./clockstuff</TT> and |
---|
1529 | <TT>./authstuff</TT> |
---|
1530 | directories of the distribution. One of these is the <TT>propdelay</TT> |
---|
1531 | program, which can compute high frequency radio propagation delays |
---|
1532 | between |
---|
1533 | any two points whose latitude and longitude are known. The program |
---|
1534 | understands |
---|
1535 | something about the phenomena which allow high frequency radio |
---|
1536 | propagation |
---|
1537 | to occur, and will generally provide a better estimate than a |
---|
1538 | calculation |
---|
1539 | based on the great circle distance. Other programs of interest include |
---|
1540 | <TT>clktest</TT>, which allows one to exercise the generic clock line |
---|
1541 | discipline, |
---|
1542 | and <TT>chutest</TT>, which runs the basic reduction algorithms used by |
---|
1543 | the daemon on data received from a serial port. |
---|
1544 | |
---|
1545 | <hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a |
---|
1546 | href=mailto:mills@udel.edu> David L. Mills <mills@udel.edu></a> |
---|
1547 | </address></a></body></html> |
---|