contrib/ntp/html/y2k.htm

   1 <html><head<title>
   2 Network Time Protocol Year 2000 Conformance Statement
   3 </title></head><body><h3>
   4 Network Time Protocol Year 2000 Conformance Statement
   5 </h3>
   6
   7 <img align=left src=pic/alice15.gif>
   8 from <i>Alice's Adventures in Wonderland</i>, by Lewis Carroll,
   9 illustrations by Sir John Tenniel
  10
  11 <p>The Mad Hatter and the March Hare are discussing whether the Teapot
  12 serial number should have two or four digits.
  13
  14 <br clear=left><hr>
  15
  16 <h4>Introduction</h4>
  17
  18 By the year 2000, the Network Time Protocol (NTP) will have been in
  19 use for over two decades and remain the longest running, continuously
  20 operating application protocol in the Internet. There is some concern,
  21 especially in government and financial institutions, that NTP might
  22 cause Internet applications to misbehave in terrible ways on the epoch
  23 of the next century. This document presents an analysis of the various
  24 hazards that might result in incorrect time values upon this epoch. It
  25 concludes that incorrect time values due to the NTP timescale, protocol
  26 design and reference implementation are highly unlikely. However, it is
  27 possible that external reference time sources used by NTP could
  28 misbehave and cause NTP servers to distribute incorrect time values to
  29 significant portions of the Internet. Note that, while this document
  30 addresses the issues specifically with respect to Unix systems, the
  31 issues are equally applicable to Windows and VMS systems.
  32
  33 <h4>The NTP Timescale</h4>
  34
  35 It will be helpful in understanding the issues raised in this document
  36 to consider the concept of a universal timescale. The conventional civil
  37 timescale used in most parts of the world is based on Universal
  38 Coordinated Time (UTC sic), formerly known as Greenwich Mean Time (GMT).
  39 UTC is based on International Atomic Time (TAI sic), which is derived
  40 from hundreds of cesium clocks in the national standards laboratories of
  41 many countries. Deviations of UTC from TAI are implemented in the form
  42 of leap seconds, which occur on average every eighteen months. For
  43 almost every computer application today, UTC represents the universal
  44 timescale extending into the indefinite past and indefinite future. We
  45 know of course that the UTC timescale did not exist prior to 1972, the
  46 Gregorian calendar did not exist prior to 1582, the Julian calendar did
  47 not exist prior to 54 BC and we cannot predict exactly when the next
  48 leap second will occur. Nevertheless, most folks would prefer that, even
  49 if we can't get future seconds numbering right beyond the next leap
  50 second, at least we can get the days numbering right until the end of
  51 reason.
  52
  53 <p>The universal timescale can be implemented using a binary counter of
  54 indefinite width and with the unit seconds bit placed somewhere in the
  55 middle. The counter is synchronized to UTC such that it runs at the same
  56 rate and the units increment coincides with the UTC seconds tick. The
  57 NTP timescale is constructed from 64 bits of this counter, of which 32
  58 bits number the seconds and 32 bits represent the fraction. With this
  59 design, the counter runs in 136-year cycles, called eras, the latest of
  60 which began with a counter value of zero at 0h 1 January 1900. The
  61 design assumption is that further low order bits, if required, are
  62 provided by local interpolation, while further high order bits, when
  63 required, are provided by external means. The important point to be made
  64 here is that the high order bits must ultimately be provided by
  65 astronomers and disseminated to the population by international means.
  66 Ultimately, should a need exist to align a particular NTP era to the
  67 current calendar, the operating system in which NTP is embedded must
  68 provide the necessary high order bits, most conveniently from the file
  69 system or flash memory.
  70
  71 <h4>The Year 2000 Era</h4>
  72
  73 With respect to the year 2000 issue, the most important thing to observe
  74 about the NTP timescale is that it knows nothing about days, years or
  75 centuries, only the seconds since the beginning of the latest era, the
  76 current one of which began on 1 January 1900. On 1 January 1970 when
  77 Unix life began, the NTP timescale showed 2,208,988,800 and on 1 January
  78 1972 when UTC life began, it showed 2,272,060,800. On the last second of
  79 year 1999, the NTP timescale will show 3,155,672,599 and one second
  80 later on the first second of the next century will show 3,155,672,600.
  81 Other than this observation, the NTP timescale has no knowledge of or
  82 provision for any of these eclectic seconds.
  83
  84 <p>The NTP timescale is almost never used directly by system or
  85 application programs. The generic Unix kernel keeps time in seconds and
  86 microseconds (or nanoseconds) to provide both time of day and interval
  87 timer functions. In order to synchronize the Unix clock, NTP must
  88 convert to and from its representation and Unix representation. Unix
  89 kernels implement the time of day function using two 32-bit counters,
  90 one representing the seconds since Unix life began and the other the
  91 microseconds or nanoseconds of the second. In principle, the seconds
  92 counter will wrap around in 136-year eras, the next of which will begin
  93 in 2106. How the particular Unix semantics interprets the counter values
  94 is of concern, but is beyond the scope of discussion here.
  95
  96 <p>While incorrect time values due to the NTP timescale and protocol
  97 design or reference implementation upon the epoch of the next century
  98 are highly unlikely, hazards remain due to incorrect software external
  99 to NTP. These hazards include the Unix kernel and library routines which
 100 convert Unix time to and from conventional civil time in seconds,
 101 minutes, hours, days and years. Although NTP uses these routines to
 102 format monitoring data displays, they are not used to read or set the
 103 NTP clock. They may in fact cause problems with certain application
 104 programs, but this is not an issue which concerns NTP correctness.
 105
 106 <p>While it is extremely unlikely that NTP will produce incorrect time
 107 values upon the epoch, it is possible that some external source to which
 108 NTP synchronizes may produce a discontinuity which could then induce a
 109 NTP discontinuity. The NTP primary (stratum 1) time servers, which are
 110 the ultimate time references for the entire NTP population, obtain time
 111 from various sources, including radio and satellite receivers and
 112 telephone modems. Not all sources provide year information and not all
 113 of these provide time in four-digit form. In point of fact, the NTP
 114 reference implementation does not use the year information, even if
 115 available. Instead, the year information is provided from the file
 116 system, which itself depends on the Unix clock.
 117
 118 <p>The NTP protocol specification requires the apparent NTP time derived
 119 from external servers to be compared to the file system time before the
 120 clock is set. If the discrepancy is over 1000 seconds, an error alarm is
 121 raised requiring manual intervention. This makes it very unlikely that
 122 even a clique of seriously corrupted NTP servers will result in
 123 incorrect time values. In the case of embedded computers with no file
 124 system, the design assumption is that the current era be established
 125 from flash memory or a clock chip previously set by manual means.
 126
 127 <p>It is essential that any clock synchronization protocol, including
 128 NTP, include provisions for multiple-server redundancy and multiple-
 129 route diversity. Past experience has demonstrated the wisdom of this
 130 approach, which protects clients against hardware and software faults,
 131 as well as incorrectly operating reference sources and sometimes even
 132 buggy software. For the most reliable service, we recommend multiple
 133 reference sources for primary servers, including a backup radio or
 134 satellite receiver or telephone modem. We also recommend that primary
 135 servers run NTP with other primary servers to provide additional
 136 redundancy and mutual backup should the reference sources themselves
 137 fail or operate incorrectly.
 138
 139 <hr><a href=index.htm><img align=left src=pic/home.gif></a><address><a
 140 href=mailto:mills@udel.edu> David L. Mills &lt;mills@udel.edu&gt;</a>
 141 </address></a></body></html>