1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
4 <meta name="generator" content="HTML Tidy, see www.w3.org">
5 <title>NTP Timescale and Leap Seconds</title>
8 <h3>NTP Timescale and Leap Seconds</h3>
10 <img align="left" src="pic/alice15.gif" alt="gif"><a href=
11 "pictures.htm">from <i>Alice's Adventures in Wonderland</i>, Lewis
14 <p>The Mad Hatter and the March Hare are discussing whether the
15 Teapot serial number should have two or four digits.<br clear=
22 <p>In the year 2001 the Network Time Protocol (NTP) has been in use
23 for over two decades and remains the longest running, continuously
24 operating application protocol in the Internet. There was some
25 concern, especially in government and financial institutions, that
26 NTP might cause Internet applications to misbehave in terrible ways
27 on the epoch of the new century, but this didn't happen. However,
28 how NTP reckons the time is important when considering the
29 relationship between NTP time and conventional civil time.</p>
31 <p>This document presents an analysis of the NTP timescale, in
32 particular the metrication relative to the conventional civil
33 timescale and when the NTP timescale rolls over in 2036. These
34 issues are also important with respect to the Unix timescale, but
35 that rollover will not happen until 2038. This document does not
36 establish a standard, nor does it present specific algorithms which
37 metricate the NTP timescale with respect to other timescales.</p>
39 <h4>The NTP Timescale</h4>
41 <p>It will be helpful in understanding the issues raised in this
42 document to consider the concept of a universal timescale. The
43 conventional civil timescale used in most parts of the world is
44 based on Coordinated Universal Time (UTC) (sic), formerly known as
45 Greenwich Mean Time (GMT). UTC is based on International Atomic
46 Time (TAI sic), which is derived from hundreds of cesium clocks in
47 the national standards laboratories of many countries. Deviations
48 of UTC from TAI are implemented in the form of leap seconds, which
49 occur on average every eighteen months.</p>
51 <p>For almost every computer application today, UTC represents the
52 universal timescale extending into the indefinite past and
53 indefinite future. We know of course that the UTC timescale did not
54 exist prior to 1972, the Gregorian calendar did not exist prior to
55 1582, the Julian calendar did not exist prior to 54 BC and we
56 cannot predict exactly when the next leap second will occur.
57 Nevertheless, most folks would prefer that, even if we can't get
58 future seconds numbering right beyond the next leap second, at
59 least we can get the days numbering right until the end of
62 <p>The universal timescale can be implemented using a binary
63 counter of indefinite width and with the unit seconds bit placed
64 somewhere in the middle. The counter is synchronized to UTC such
65 that it runs at the same rate (also the rate of TAI) and the units
66 increment coincides with the UTC seconds tick. The NTP timescale is
67 constructed from 64 bits of this counter, of which 32 bits number
68 the seconds and 32 bits represent the fraction. With this design,
69 the counter runs in 136-year cycles, called eras, the latest of
70 which began with a counter value of zero at 0h 1 January 1900. The
71 next era will begin when the seconds counter rolls over sometime in
72 2036. The design assumption is that further low order bits, if
73 required, are provided by local interpolation, while further high
74 order bits, when required, are provided by external means.</p>
76 <p>The important point to be made here is that the high order bits
77 must ultimately be provided by astronomers and disseminated to the
78 population by international means. Ultimately, should a need exist
79 to align a particular NTP era to the current calendar, the
80 operating system in which NTP is embedded must provide the
81 necessary high order bits, most conveniently from the file system
84 <p>With respect to the recent year 2000 issue, the most important
85 thing to observe about the NTP timescale is that it knows nothing
86 about days, years or centuries, only the seconds since the
87 beginning of the current era which began on 1 January 1900. On 1
88 January 1970 when Unix life began, the NTP timescale showed
89 2,208,988,800 and on 1 January 1972 when UTC life began, it showed
90 2,272,060,800. On the last second of the year 1999, the NTP
91 timescale showed 3,155,673,599 and one second later on the first
92 second of the next century showed 3,155,673,600. Other than this
93 observation, the NTP timescale has no knowledge of or provision for
94 any of these eclectic seconds.</p>
96 <h4>Conversion to Other Timescales</h4>
98 <p>The NTP timescale is almost never used directly by system or
99 application programs. The generic Unix kernel keeps time in seconds
100 and microseconds (or nanoseconds) to provide both time of day and
101 interval timer functions. In order to synchronize the Unix clock,
102 NTP must convert to and from NTP representation and Unix
103 representation. Unix kernels implement the time of day function
104 using two 32-bit counters, one representing the signed seconds
105 since Unix life began and the other the microseconds or nanoseconds
106 of the second. In principle, the seconds counter will change sign
107 in 2038. How the particular Unix semantics interprets the counter
108 values is of concern, but is beyond the scope of discussion
111 <p>While incorrect NTP time values are unlikely in a properly
112 configured subnet using strong cryptography, redundant sources and
113 diverse network paths, hazards remain due to incorrect software
114 external to NTP. These include the Unix kernel and library routines
115 which convert NTP time to and from Unix time and to and from
116 conventional civil time in seconds, minutes, hours, days and years.
117 Although NTP uses these routines to format monitoring data
118 displays, they are not used to read or set the NTP clock. They may
119 in fact cause problems with certain application programs, but this
120 is not an issue which concerns NTP correctness.</p>
122 <p>It is possible that some external source to which NTP
123 synchronizes may produce a discontinuity which could then induce a
124 NTP discontinuity. The NTP primary (stratum 1) time servers, which
125 are the ultimate time references for the entire NTP population,
126 obtain time from various sources, including radio and satellite
127 receivers and telephone modems. Not all sources provide year
128 information and not all of these provide time in four-digit form.
129 In point of fact, the NTP reference implementation does not use the
130 year information, even if available. Instead, the year information
131 is provided from the file system, which itself depends on the Unix
134 <p>Most computers include a time-of-year (TOY) clock chip which
135 maintains the time when the power is off. When the operating system
136 is booted, the system clock is set from the chip. As the chip does
137 not record the year, this value is determined from the datestamp on
138 a system configuration file. For this to be correct, the filestamp must by updated at least once each year. The NTP protocol specification
139 requires the apparent NTP time derived from external servers to be
140 compared to the system time before the clock is set. If the
141 discrepancy is over 1000 seconds, an error alarm is raised
142 requiring manual intervention. This makes it very unlikely that
143 even a clique of seriously corrupted NTP servers will result in
144 grossly incorrect time values. When the system clock is synchronized to
145 NTP, the TOY chip is corrected to system time on a regular
148 <h4>Timescale Resolution and the Tick Interval</h4>
150 <p>Modern computer clocks use a hardware counter to generate processor interrupts at tick intervals in the order of a few milliseconds. At each tick the processor increments the software system clock by the number of microseconds or nanoseconds in the tick. The software resolution of the system clock is defined as the tick interval. Most modern processors implement some kind of high resolution hardware counter that can be used to interpolate the interval between the most recent tick and the actual clock reading. The hardware resolution of the system clock is defined as the time between increments of this counter. However, the actual reading latency due to the kernel interface and interpolation code can range from a few tens of microseconds in older processors to under a microsecond in modern processors.</p>
152 <p>System clock correctness principles require that clock readings must be always monotonically increasing, so that no two clock readings will be the same. As long as the reading latency exceeds the hardware resolution, this behavior is guaranteed. With reading latencies dropping below the microsecond in modern processors, the system clock in modern operating systems runs in nanoseconds, rather than the microseconds used in the original Unix kernel. With processor speeds exceeding 1 GHz, this assumption may be in jeopardy.
154 <h4>Leap Seconds</h4>
156 <p>The International Earth Rotation Service (IERS) uses
157 astronomical observations provided by USNO and other observatories
158 to determine UTC, which is syntonic (identical frequency) with TAI
159 but offset by a integral number of seconds. Starting from apparent
160 mean solar time as observed, the UT0 timescale is determined using
161 corrections for Earth orbit and inclination (the Equation of Time,
162 as used by sundials), the UT1 (navigator's) timescale by adding
163 corrections for polar migration and the UT2 timescale by adding
164 corrections for known periodicity variations. UTC is based on UT1,
165 which is presently fast relative to TAI by a fraction of a second
166 per year. Since the UTC timescale runs at the TAI rate, when the
167 magnitude of the UT1 correction approaches 0.5 second, a leap
168 second is inserted or deleted in the UTC timescale on the last day
169 of June or December.</p>
171 <p>For the most precise coordination and timestamping of events
172 since 1972, it is necessary to know when leap seconds are
173 implemented in UTC and how the seconds are numbered. The insertion
174 of leap seconds into UTC is currently the responsibility of the
175 IERS, which is located at the Paris Observatory. As specified in
176 CCIR Report 517, a leap second is inserted following second
177 23:59:59 on the last day of June or December and becomes second
178 23:59:60 of that day. A leap second would be deleted by omitting
179 second 23:59:59 on one of these days, although this has never
180 happened. A table of historic leap seconds and the NTP time when
181 each occurred is available via FTP from any NIST NTP server.</p>
183 <p>The UTC timescale thus ticks in standard (atomic) seconds and
184 was set to an initial offset of 10 seconds relative to TAI at 0h
185 MJD 41,318.0 according to the Julian calendar or 0h on 1 January
186 1972 according to the Gregorian calendar. This established the
187 first tick of the UTC era and its reckoning with these calendars.
188 Subsequently, the UTC timescale has marched backward relative to
189 the TAI timescale exactly one second on scheduled occasions
190 recorded in the institutional memory of our civilization. Note in
191 passing that leap second adjustments affect the number of seconds
192 per day and thus the number of seconds per year. Apparently, should
193 we choose to worry about it, the UTC clock, Gregorian calendar and
194 various cosmic oscillators will inexorably drift apart with time
195 until rationalized by some future papal bull.</p>
197 <h4>Reckoning with NTP and UTC Leap seconds</h4>
199 <p>The NTP timescale is based on the UTC timescale, but not
200 necessarily always coincident with it. At the first tick of the UTC
201 Era, which began at 0h on 1 January 1972 (MJD 41,318.0) the NTP
202 clock read 2,272,060,800, representing the number of standard
203 seconds since the beginning of the NTP era at 0h on 1 January 1900
204 (MJD 15,021.0) according to the Gregorian calendar. The insertion
205 of leap seconds in UTC and subsequently into NTP does not affect
206 the UTC or NTP oscillator frequency, only the conversion between
207 NTP network time and UTC civil time. However, since the only
208 institutional memory available to NTP are the UTC broadcast
209 services, the NTP timescale is in effect reset to UTC as each
210 broadcast timecode is received. Thus, when a leap second is
211 inserted in UTC and subsequently in NTP, knowledge of all previous
212 leap seconds is lost.</p>
214 <p>Another way to describe this is to say there are as many NTP
215 timescales as historic leap seconds. In effect, a new timescale is
216 established after each new leap second. Thus, all previous leap
217 seconds, not to mention the apparent origin of the timescale
218 itself, lurch forward one second as each new timescale is
219 established. If a clock synchronized to NTP in early 2001 was used
220 to establish the UTC epoch of an event that occurred in early 1972
221 without correction, the event would appear 22 seconds late.
222 However, NTP primary time servers resolve the epoch using the
223 broadcast timecode, so that the NTP clock is set to the broadcast
224 value on the current timescale. As a result, for the most precise
225 determination of epoch relative to the historic Gregorian calendar
226 and UTC timescale, the user must subtract from the apparent NTP
227 epoch the offsets derived from the NIST table. This is a feature of
228 almost all present day time distribution mechanisms.</p>
230 <p>The obvious question raised by this scenario is what happens
231 during the leap second when NTP time stops and the clock remains
232 unchanged. If the precision time kernel modifications have been
233 implemented, the kernel includes a state machine that implements
234 the actions required by the scenario. At the exact instant of the
235 leap, the logical clock is stepped backward one second. However,
236 the routine that actually reads the clock is constrained never to
237 step backwards, unless the step is significantly larger than one
238 second, which might occur due to explicit operator direction.</p>
240 <p>In this design time stands still during the leap second, but is correct commencing with the next second. Since clock readings must be positive monotonic, the apparent time will increase by one nanosecond for each reading. At the end of the second the apparent time may be ahead of the actual time depending on how many times the clocks was read during the second. Eventually, the actual time will catch up with the apparent time and operation continues normally.</p>
243 <a href="index.htm"><img align="left" src="pic/home.gif" alt=
246 <address><a href="mailto:mills@udel.edu">David L. Mills
247 <mills@udel.edu></a></address>
uqs's projects / games.git / blob