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>
7 <img align=left src=pic/tonea.gif>
8 From NBS Special Publication 432 (out of print)
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.
22 <P><TT>ntpd</TT> includes a complete implementation of the NTP Version
23 3 specification, as defined in:
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>
32 href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305a.pdf>
34 href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305b.ps>
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>
40 href=http://www.eecis.udel.edu/~mills/database/rfc/rfc1305/rfc1305c.pdf>
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
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
71 HREF="http://www.eecis.udel.edu/~mills/database/rfc2030.txt">
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.
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
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.
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.
138 <H4>How NTP Works</H4>
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
145 Coordinated Time (UTC) using the best available source and available
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
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
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
158 provisions can made to nominate one of them as a phantom UTC source.
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
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
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
172 them to. If your network is isolated and you cannot access other
174 servers across the Internet, a radio clock may make a good investment.
176 <P>Time is distributed through a hierarchy of NTP servers, with each
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
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
184 broadcasts from radio stations which explicitly provide a standard time
185 service. A stratum-2 server is one which is currently obtaining time
187 a stratum-1 server, a stratum-3 server gets its time from a stratum-2
189 and so on. To avoid long lived synchronization loops the number of
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
199 time should be viewed with a certain amount of distrust. NTP really
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
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
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
214 server doesn't access directly can also provide good backup service).
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
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.
223 an association in symmetric-active mode (usually indicated by a
225 declaration in the configuration file) indicates to the remote server
227 one wishes to obtain time from the remote server and that one is also
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
232 via diverse network paths, which is presently the case for most stratum-
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
237 configuration file) indicates that one wishes to obtain time from the
239 server, but that one is not willing to provide time to the remote
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
247 <P>Where the requirements in accuracy and reliability are modest,
249 can be configured to use broadcast and/or multicast modes. These modes
250 are not normally utilized by servers with dependent clients. The
252 of these modes is that clients do not need to be configured for a
254 server, so that all clients operating can use the same configuration
256 Broadcast mode requires a broadcast server on the same subnet, while
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
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
264 many multicast servers will be used, since all operate on the same group
267 <P>Where the maximum accuracy and reliability provided by NTP are
269 clients and servers operate in either client/server or symmetric modes.
270 Symmetric modes are most often used between two or more servers
272 as a mutually redundant group. In these modes, the servers in the group
273 members arrange the synchronization paths for maximum performance,
275 on network jitter and propagation delay. If one or more of the group
277 fail, the remaining members automatically reconfigure as required.
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
283 protection against malfunctions or protocol attacks.
285 <P>Servers that provide synchronization to a sizeable population of
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
291 modes. This provides protection against malfunctions in which one or
293 servers fail to operate or provide incorrect time. The NTP algorithms
295 been specifically engineered to resist attacks where some fraction of
297 configured synchronization sources accidently or purposely provide
299 time. In these cases a special voting procedure is used to identify
301 sources and discard their data.
303 Configuring Your Subnet</H4>
304 At startup time the <TT>ntpd</TT> daemon running on a host reads the
306 configuration information from a file, usually <TT>/etc/ntp.conf</TT>,
307 unless a different name has been specified at compile time. Putting
309 in this file which will enable the host to obtain time from somewhere
311 is usually the first big hurdle after installation of the software
313 which is described in the <A HREF="build.htm">Building and Installing
315 Distribution</A> page. At its simplest, what you need to do in the
317 file is declare the servers that the daemon should poll for time
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.
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
326 that coordinates network services, including NTP. Where available, the
327 addresses of appropriate servers can be provided by that department.
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
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-
335 service. Some of these are listed in the list of public time servers,
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
340 voluntarily by various site administrators. There are other ways to
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.
345 <P>It is vital to carefully consider the issues of robustness and
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
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
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
358 its clock accumulating serious error approaching a second, for instance.
359 Selecting at least three sources from different operating
361 where possible, is the minimum recommended, although a lesser number
363 provide acceptable service with a degraded degree of robustness.
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
368 these servers provide synchronization for hundreds of clients in many
370 and could, along with the network access paths, become seriously
372 if large numbers of workstation clients requested synchronization
374 Therefore, workstations located in sparsely populated administrative
376 with no local synchronization infrastructure should request
378 from nearby stratum-2 servers instead. In most cases the keepers of
380 servers in the lists of public servers provide unrestricted access
382 prior permission; however, in all cases it is considered polite to
384 the administrator listed in the file upon commencement of regular
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
390 in the local infrastructure, especially in cases of dial-up access to
394 <P>In the case of a gateway or file server providing service to a
396 number of workstations or file servers in an enterprise network it is
398 more important to provide multiple, redundant sources of synchronization
399 and multiple, diversity-routed, network access paths. The preferred
401 is at least three administratively coordinated time servers providing
403 throughout the administrative domain including campus networks and
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
412 level used by the local time servers, as well as at least one
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
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
424 <P>The stratum level to be used by the local time servers is an
426 choice. As a matter of policy, and in order to reduce the load on the
428 servers, it is desirable to use the highest stratum consistent with
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
434 from stratum-1 primary servers listed for public access. When choosing
435 sources away from the primary sources, the particular synchronization
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
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
444 primary sources of synchronization are lost throughout the subnet, the
445 remaining servers on that subnet can form temporary loops and, if the
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
452 to local application programs.
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
457 above anyway and connect the radio clock to one of the local servers.
459 server is then encouraged to participate in a special primary-server
461 in which each radio-equipped server peers with several other similarly
462 equipped servers. In this way the radio-equipped server may provide
464 as well as receive synchronization, should the local or remote radio
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
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
472 advised, and in practice for most primary servers today, to employ the
473 authentication or access-control features of the NTP specification in
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
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
483 file servers, will operate at stratum 3 and dependent workstations at
485 4. Engineered correctly, such a subnet will survive all but the most
487 failures or even hostile penetrations of the various, distributed
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.
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
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
502 broadcasts and do not need to send anything.
504 <P>When planning your network you might, beyond this, keep in mind a few
505 generic don'ts, in particular:
508 Don't synchronize a local time server to another peer at the same
510 unless the latter is receiving time from lower stratum sources the
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>
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
523 much greater configuration churn in the high stratum clients such as
528 Don't synchronize more than one time server in a particular
530 domain to the same time server outside that domain. Such a practice
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>
536 There are many useful exceptions to these rules. When in doubt, however,
539 Configuring Your Server or Client</H4>
540 As mentioned previously, the configuration file is usually called
542 This is an ASCII file conforming to the usual comment and whitespace
544 A working configuration file might look like (in this and other
546 do not copy this directly):
547 <PRE> # peer configuration for host whimsy
548 # (expected to operate at stratum 2)
550 server rackety.udel.edu
551 server umd1.umd.edu
552 server lilben.tn.cornell.edu
554 driftfile /etc/ntp.drift</PRE>
555 (Note the use of host names, although host addresses in dotted-quad
557 can also be used. It is always preferable to use names rather than
559 since over time the addresses can change, while the names seldom
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
565 servers declared (the first two) have radio clocks and usually run at
567 1. The third server in the list has no radio clock, but is known to
569 associations with a number of stratum 1 peers and usually operates at
571 2. Of particular importance with the last host is that it maintains
573 with peers besides the two stratum 1 peers mentioned. This can be
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
580 <P>Unless restricted using facilities described later, this host can
582 synchronization to dependent clients, which do not have to be listed in
583 the configuration file. Associations maintained for these clients are
585 and result in no persistent state in the host. These clients are
587 not visible using the <TT>ntpq</TT> program included in the
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.
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
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
603 global Internet, while minimizing the possibility of instability within
604 the domain itself. A time server in one domain can in principle heal
606 domain temporarily isolated from all other sources of synchronization.
607 However, it is probably unwise for a casual workstation to bridge
609 of the local domain which have become temporarily isolated.
611 <P>Note the inclusion of a <TT>driftfile</TT> declaration. One of the
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
617 a good estimate of this (and it needs a good estimate to synchronize
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.
622 <TT>driftfile</TT> declaration indicates to the daemon the name of a
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
628 the frequency estimate. Since this is a desirable feature, a
630 declaration should always be included in the configuration file.
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
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
638 the frequency estimate, every effort should be made to operate the
640 on a continuous basis and minimize the intervals when for some reason it
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.
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>".
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.
665 Ntp4 Versus Previous Versions</H4>
666 There are several items of note when dealing with a mixture of
668 and previous distributions of NTP Version 2 (<TT>ntpd</TT>) and NTP
670 1 (<TT>ntp3.4</TT>). The <TT>ntp4</TT> implementation conforms to the
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
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
679 of the <TT>server</TT>, <TT>peer</TT>, <TT>broadcast </TT>and
681 </TT>command can be used to change the default. In unconfigured
683 associaitons, the daemon always replies in the same version as the
686 <P>An NTP implementation conforming to a previous version specification
687 ordinarily discards packets from a later version. However, in most
689 documented in RFC-1305, The version 2 implementation is compatible with
690 the version 3 algorithms and protocol. The version 1 implementation
692 most of the version 2 algorithms, but without important features for
694 selection and robustness. Nevertheless, in most respects the NTP
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
700 that in some situations synchronization with previous versions will
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,
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
709 to indicate which version to use when polling. Hence the entries
710 <PRE> # specify NTP version 1
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
718 2 packets to be sent to apple.com. If you are testing <TT>ntpd</TT>
720 previous version servers you will need to be careful about this. Note
722 as indicated in the RFC-1305 specification, there is no longer support
723 for the original NTP specification, once called NTP Version 0.
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
729 the work done in responding to their polls, and normally retains no
731 of these pollers. Sometimes, however, it is interesting to be able to
733 who is polling the server, and how often, as well as who has been
735 other types of queries to the server.
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
740 from each packet which is received by the server. This feature is
742 enabled, but can be disabled if desired using the configuration file
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.
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
753 3 specification. The major drawback is that, while the internal
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.
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
763 <PRE> (source_addr & mask) == (address &
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
768 with this entry are used to control the access.
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>
774 The flags associated with the entry are specified textually. For
776 the <TT>notrust</TT> flag indicates that hosts matching this entry,
778 treated normally in other respects, shouldn't be trusted to provide
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
783 There are many more flags, see the <A HREF="ntpd.htm"><TT>ntpd</TT>
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
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
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
797 restrict default notrust nomodify
799 # these guys are trusted for time, but no
800 modifications allowed
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
806 # the local addresses are unrestricted
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
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
816 keyword, it defaults to 255.255.255.255. Note that the address
818 matches three entries in the table, the default entry (mask 0.0.0.0),
820 entry for net 128.100 (mask 255.255.0.0) and the entry for the host
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.
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
830 which you don't wish to be applied to your configured peers, you must
832 those restrictions for the configured peers with additional
834 declarations mentioning each peer separately.
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
842 computed using either the Data Encryption Standard (DES) or Message
844 (MD5) algorithms. Note that, while either of these algorithms provide
846 protection from message- modification attacks, distribution of the
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
851 algorithm is not included in the current distribution. Directions for
853 it in other countries is in the <A HREF="build.htm">Building and
855 the Distribution</A> page. With either algorithm the receiving peer
857 the checksum and compares it with the one included in the packet. For
859 to work, the peers must share at least one encryption key and,
861 must associate the shared key with the same key ID.
863 <P>This facility requires some minor modifications to the basic packet
864 processing procedures, as required by the specification. These
866 are enabled by the <TT>enable auth</TT> configuration declaration, which
867 is currently the default. In authenticated mode, peers which send
869 packets, peers which send authenticated packets which the local server
870 is unable to decrypt and peers which send authenticated packets
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
875 by many key IDs), it is possible to declare only a subset of these as
877 This allows the server to share keys with a client which requires
879 time and which trusts the server, but which is not trusted by the
881 Also, some additional configuration language is required to specify the
882 key ID to be used to authenticate each configured peer association.
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
890 peer 128.100.49.105 key 22 #
891 suzuki.ccie.utoronto.ca
892 peer 128.8.10.1 key 4 #
894 peer 192.35.82.50 key 6 #
895 lilben.tn.cornell.edu
897 keys /usr/local/etc/ntp.keys # path for
899 trustedkey 1 2 14 15 #
901 requestkey
902 15 #
903 key (7) for accessing server variables
904 controlkey
905 15 #
906 key (6) for accessing server variables
908 authdelay
909 0.000094 # authentication delay
911 There are a couple of previously unmentioned things in here. The
913 </TT>line specifies the path to the keys file (see below and the
915 document page for details of the file format). The <TT>trustedkey</TT>
916 declaration identifies those keys that are known to be uncompromised;
918 remainder presumably represent the expired or possibly compromised keys.
919 Both sets of keys must be declared by key identifier in the
921 file described below. This provides a way to retire old keys while
923 the frequency of delicate key-distribution procedures. The
925 line establishes the key to be used for mode-6 control messages as
927 in RFC-1305 and used by the <TT>ntpq</TT> utility program, while the
929 </TT>line establishes the key to be used for mode-7 private control
931 used by the <TT>ntpdc</TT> utility program. These keys are used to
933 unauthorized modification of daemon variables.
935 <P>Ordinarily, the authentication delay; that is, the processing time
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
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
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
949 <PRE> # for DES keys
951 authspeed -n 30000 auth.samplekeys
952 # for MD5 keys
954 authspeed -mn 30000 auth.samplekeys</PRE>
955 Additional utility programs included in the <TT>./authstuff</TT>
957 can be used to generate random keys, certify implementation correctness
958 and display sample keys. As a general rule, keys should be chosen
960 except possibly the request and control keys, which must be entered by
961 the user as a password.
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
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
979 # the following 3 keys are identical
981 10 A SeCReT
982 10 N
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-
990 character string in 7-bit ASCII representation, with each character
992 for a key octet (like a Unix password). An <TT>S</TT> indicates a DES
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>
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
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
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.
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
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
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
1021 Three utility query programs are included with the distribution,
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
1026 messages. Since it uses the standard control protocol specified in RFC-
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.
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
1036 source of synchronization, usually a radio clock. It works with both
1038 2 and version 3 servers, but not version 1.
1040 <P><TT>ntpdc</TT> is a horrid program which uses NTP private mode-7
1042 messages to query local or remote servers. The format and contents of
1044 messages are specific to this version of <TT>ntpd</TT> and some older
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
1050 is that it provides a user interface to the run time reconfiguration
1052 See the respective document pages for details on the use of these
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
1059 is at run time. The configuration file is read only after the rest of
1061 server has been initialized into a running default-configured state.
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
1066 the feature is more important for maintenance. Nevertheless, run time
1068 works very nicely for Unix servers as well.
1070 <P>Nearly all of the things it is possible to configure in the
1072 file may be altered via NTP mode-7 messages using the <TT>ntpdc</TT>
1074 Mode-6 messages may also provide some limited configuration
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
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>
1083 have a slightly different encoding than the usual interpretation:
1084 <PRE>
1085 Value Action
1087
1088 00 &nbs
1089 p; The daemon passes the leap bits of its
1090
1091
1092 synchronisation source (usual mode of operation)
1094 01/10 A leap
1095 second is added/deleted
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
1106 To enable the facilities one must, in addition to specifying the
1108 of a keys file, indicate in the configuration file the key IDs to be
1110 for authenticating reconfiguration commands. Hence the following
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
1116 requestkey 65535 # for mode-7
1118 controlkey 65534 # for mode-6
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.
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
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
1131 request and control authentication keys typeable (in ASCII format) from
1134 Name Resolution</H4>
1135 <TT>ntpd</TT> includes the capability to specify host names requiring
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
1140 and the interface to the Unix resolver routines is synchronous. The
1142 and delays resulting from name-resolver clanking can be unacceptable
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.
1148 <P>In order to prevent configuration delays due to the name resolver,
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>
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
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
1160 omitted from its configuration.
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
1165 uses. If temporary resolver failures occur, the resolver will
1167 retry the requests until a definite response is received. The program
1169 continue to run until all entries have been resolved.
1171 <A NAME="frequency_tolerance">Dealing with Frequency Tolerance
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
1177 of those components suitable for use in relatively inexpensive
1179 platforms. For those platforms meeting this tolerance, NTP will
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.
1186 <P>However, in the case of certain notorious platforms, in particular
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
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
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
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
1203 (this latter behaviour is a misfeature, and is the only reason the
1205 code needs to concern itself with the internal implementation of
1207 at all). In addition, the stock Unix implementation considers it an
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
1213 and <TT>tickadj</TT>. This ensures that all adjustments given to
1215 are an even multiple of <TT>tickadj</TT> microseconds and computes the
1216 largest adjustment that can be completed in the adjustment interval
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
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
1225 cases they will substantially improve the general accurace of the time
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
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
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
1240 directory of the distribution. Note that the latter program will also
1242 an optimal value of <TT>tickadj</TT> for NTP use based on the kernel's
1243 value of <TT>tick</TT>.
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.
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>.
1263 <P>In order to maintain reasonable correctness bounds, as well as
1265 good accuracy with acceptable polling intervals, <TT>ntpd</TT> will
1267 if the frequency error is greater than 500 PPM. For machines with a
1269 of <TT>tick</TT> in the 10-ms range, a change of one in the value of
1271 will change the frequency by about 100 PPM. In order to determine the
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
1276 to an outside source (eyeball-and-wristwatch will do) over a day or
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
1284 off the clock/calendar chip fiddle. This line can be added to the
1286 configuration file to automatically set the kernel variables at boot
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
1292 reasonable time and would make their <TT>adjtime()</TT> system call
1294 the slew it is given exactly, independent of the value of
1296 all this could go away. This is in fact the case on many current Unix
1299 Tuning Your Subnet</H4>
1300 There are several parameters available for tuning the NTP subnet for
1302 accuracy and minimum jitter. One of these is the <TT>prefer</TT>
1304 declaration described in <A HREF="prefer.htm">Mitigation Rules and the
1305 <TT>prefer</TT> Keyword </A>documentation page. When more than one
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
1311 successive readings of the same server. The result is usually a set of
1312 surviving servers that are apparently statistically equivalent in
1314 jitter and stability. The population of survivors remaining in this set
1315 depends on the individual server characteristics measured during the
1317 process and may vary from time to time as the result of normal
1319 variations. In LANs with high speed RISC-based time servers, the
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>.
1325 <P>When only the smallest residual jitter can be tolerated, it may be
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
1332 peer rackety.udel.edu prefer
1333 # preferred server</PRE>
1334 The preferred server will always be included in the surviving
1336 regardless of its characteristics and as long as it survives preliminary
1337 sanity checks and validation procedures.
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
1345 should normally be used in all cases in order to prefer an attached
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.
1351 Provisions for Leap Seconds and Accuracy Metrics</H4>
1352 <TT>ntpd</TT> understands leap seconds and will attempt to take
1354 action when one occurs. In principle, every host running ntpd will
1356 a leap second in the local timescale in precise synchronization with
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.
1361 these bits are propagated throughout the subnet depending on these
1363 by the NTP protocol itself and automatically implemented by
1365 and the time- conversion routines of each host. The implementation is
1367 of the idiosyncrasies of the particular radio clock, which vary widely
1368 among the various devices, as long as the idiosyncratic behavior does
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
1373 While provisions for leap seconds have been carefully crafted so that
1375 timekeeping immediately before, during and after the occurrence of a
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-
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
1386 programs to access it. This may be a topic for further development.
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
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
1396 (i.e., refers to a particular clock driver) and <I>u</I> is a unit
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
1401 of clocks of the same type on the same server, should such magnificent
1402 redundancy be required.
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
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
1411 peer, should this stretch of imagination ever be useful. As a concession
1412 to the need to sometimes transmit additional information to clock
1414 an additional configuration file is available: the <TT>fudge</TT>
1416 This enables one to specify the values of two time quantities, two
1418 values and two flags, the use of which is dependent on the particular
1420 driver. For example, to configure a PST radio clock which can be
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
1425 an imprecise system clock and with the driver set to disbelieve the
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.
1439 Towards the Ultimate Tick</H4>
1440 This section considers issues in providing precision time
1442 in NTP subnets which need the highest quality time available in the
1444 technology. These issues are important in subnets supporting real-time
1445 services such as distributed multimedia conferencing and wide-area
1447 control and monitoring.
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
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
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
1459 of precision time is available, such as a PPS signal produced by a
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
1465 places where radio clocks are not available. In these cases special
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
1470 timing and resolve the seconds numbering.
1472 <P>Most available radio clocks can provide time to an accuracy in the
1474 of milliseconds, depending on propagation conditions, local noise levels
1475 and so forth. However, as a practical matter, all clocks can
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
1481 the disciplined local clock oscillator and the decoded time message
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
1488 features it is possible to achieve accuracies in the order of a few tens
1489 of microseconds with a fast RISC- based platform.
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
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
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
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
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
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
1514 by the radio or the time determined by NTP in absence of the radio is
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
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
1522 PPS support is disabled and the timecode used directly to control the
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
1533 any two points whose latitude and longitude are known. The program
1535 something about the phenomena which allow high frequency radio
1537 to occur, and will generally provide a better estimate than a
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
1542 and <TT>chutest</TT>, which runs the basic reduction algorithms used by
1543 the daemon on data received from a serial port.
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>
projects / dragonfly.git / blob