ntplogtemp: Record nvme temperatures on Asahi
[ntpsec.git] / docs / warp.adoc
blob89024f3930b7ed58ed17bafb9be19d1dfbe8a296
1 = How NTP Works
2 include::include-html.ad[]
4 == Related Links
6 include::includes/special.adoc[]
7 include::includes/external.adoc[]
9 == Table of Contents
11 * link:#intro[Introduction and Overview]
12 * link:#scale[NTP Timescale and Data Formats]
13 * link:#arch[Architecture and Algorithms]
15 '''''
17 == Abstract
19 [abstract]
20 This page and its dependencies contain a technical description of the
21 Network Time Protocol (NTP) architecture and operation. It is intended
22 for administrators, operators and monitoring personnel. Additional
23 information for nontechnical readers can be found in the white paper
24 {millshome}exec.html[Executive Summary: Computer
25 Network Time Synchronization]. While this page and its dependencies are
26 primarily concerned with NTP, additional information on related
27 protocols can be found in the white papers
28 {millshome}ptp.html[IEEE 1588 Precision Time
29 Protocol (PTP)] and {millshome}proximity.html[Time
30 Synchronization for Space Data Links]. Note that reference to a page in
31 this document collection is to a page in the collection, while reference
32 to a _white paper_ is to a document at the
33 {millshome}ntp.html[Network Time Synchronization
34 Research Project] web site.
37 [[intro]]
38 == Introduction and Overview
40 NTP time synchronization services are widely available in the public
41 Internet. The public NTP subnet currently includes several thousand
42 servers in most countries and on every continent of the globe, including
43 Antarctica, and sometimes in space and on the sea floor.
45 The NTP subnet operates with a hierarchy of levels, where each level is
46 assigned a number called the stratum. Stratum 1 (primary) servers at the
47 lowest level are directly synchronized to national time services via
48 satellite, radio or telephone modem. Stratum 2 (secondary) servers at
49 the next higher level are synchronized to stratum 1 servers and so on.
50 Normally, NTP clients and servers with a relatively small number of
51 clients do not synchronize to public primary servers. There are several
52 hundred public secondary servers operating at higher strata and are the
53 preferred choice.
55 This page presents an overview of the NTP implementation included in
56 this software distribution. We refer to this implementation as the
57 _reference implementation_ only because it was used to test and validate
58 the NTPv4 specification RFC 5905. It is best read in conjunction with
59 the briefings and white papers on the
60 {millshome}ntp.html[Network Time Synchronization
61 Research Project] page. An executive summary suitable for management and
62 planning purposes is in the white paper
63 {millshome}exec.html[Executive Summary: Computer
64 Network Time Synchronization].
66 [[scale]]
67 == NTP Timescale and Data Formats
69 NTP clients and servers synchronize to the Coordinated Universal Time
70 (UTC) timescale used by national laboratories and disseminated by radio,
71 satellite and telephone modem. This is a global timescale independent of
72 geographic position. There are no provisions to correct for local time
73 zone or daylight savings time; however, these functions can be performed
74 by the operating system on a per-user basis.
76 The UT1 timescale, upon which UTC is based, is determined by the
77 rotation of the Earth about its axis. The Earth rotation is gradually
78 slowing down relative to International Atomic Time (TAI). In order to
79 rationalize UTC with respect to TAI, a leap second is inserted at
80 intervals, historically averaging about 18 months, as determined by the
81 https://www.iers.org/IERS/EN/Home/home_node.html [International Earth
82 Rotation Service (IERS)]. Reckoning with leap seconds in the NTP
83 timescale is described in the white paper
84 {millshome}leap.html[The NTP Timescale and Leap Seconds].
86 The historic insertions are documented in the +leap-seconds.list+ file,
87 which can be downloaded from the NIST FTP servers. This file is updated
88 at intervals not exceeding six months. Leap second warnings are
89 disseminated by the national laboratories in the broadcast timecode
90 format. These warnings are propagated from the NTP primary servers via
91 other server to the clients by the NTP on-wire protocol. The leap second
92 is implemented by the operating system kernel, as described in the white
93 paper {millshome}leap.html[The NTP Timescale and
94 Leap Seconds]. Implementation details are described on the
95 link:leap.html[Leap Second Processing] page.
97 image:pic/time1.gif[]
99 Figure 1. NTP Timestamp format
101 Figure 1 shows the timestamp format used in packet headers exchanged
102 between clients and servers.  Ordinarily, this timestamp format is not
103 seen by application programs, which converts it to native formats such
104 as ISO 8601 or RFC 822-style Gregorian-calendar dates.
106 The timestamp format spans 136 years, called an _era_. Conceptually,
107 it is helpful to think of an absolute dates as being a tuple of one of
108 these timestamps and an era number. The current era, era 0, began on 1
109 January 1900, while the next one begins in 2036.
111 Details on converting between era-timestamp pairs and timestamps are
112 in the white paper {millshome}y2k.html[The NTP Era and Era
113 Numbering]. The NTP protocol will synchronize correctly, regardless of
114 era, as long as the system clock is set initially within 68 years (a
115 half-era) of the correct time. Further discussion on this issue is in
116 the white paper {millshome}time.html[NTP Timestamp Calculations].
118 [[arch]]
119 == Architecture and Algorithms
121 image:pic/fig_3_1.gif[]
123 Figure 2. NTP Daemon Processes and Algorithms
125 The overall organization of the NTP architecture is shown in Figure 2.
126 It is useful in this context to consider the implementation as both a
127 client of upstream (lower stratum) servers and as a server for
128 downstream (higher stratum) clients. It includes a pair of peer/poll
129 processes for each reference clock or remote server used as a
130 synchronization source. Packets are exchanged between the client and
131 server using the _on-wire protocol_ described in the white paper
132 {millshome}onwire.html[Analysis and Simulation of
133 the NTP On-Wire Protocols]. The protocol is resistant to lost, replayed
134 or spoofed packets.
136 The poll process sends NTP packets at intervals ranging from 1 s to
137 2^17 s (36.4 hr). The intervals are managed as described on the
138 link:poll.html[Poll Process] page to maximize accuracy while
139 minimizing network load. The peer process receives NTP packets and
140 performs the packet sanity tests described on the
141 link:decode.html[Event Messages and Status Words] page
142 and link:decode.html#flash[flash status word]. The flash status word
143 reports in addition the results of various access control and security
144 checks described in the white paper
145 {millshome}security.html[NTP Security Analysis]. A
146 sophisticated traffic monitoring facility described on the
147 link:rate.html[Rate Management and the Kiss-o'-Death Packet] page
148 protects against denial-of-service (DoS) attacks.
150 Packets that fail one or more of these tests are summarily discarded.
151 Otherwise, the peer process runs the on-wire protocol that uses four raw
152 timestamps: the _origin timestamp_ _T_~1~ upon departure of the client
153 request, the _receive timestamp_ _T_~2~ upon arrival at the server, the
154 _transmit timestamp_ _T_~3~ upon departure of the server reply, and the
155 _destination timestamp_ _T_~4~ upon arrival at the client. These
156 timestamps, which are recorded by the +rawstats+ option of the
157 link:monopt.html#filegen[+filegen+] command, are used to calculate the
158 clock offset and roundtrip delay samples:
160 [verse]
161 delay = (_T_~4~ - _T_~1~) - (_T_~3~ - _T_~2~).
163 The offset and delay statistics for one or more peer processes are
164 processed by a suite of mitigation algorithms. The algorithm described
165 on the link:filter.html[Clock Filter Algorithm] page selects the offset
166 and delay samples most likely to produce accurate results. Those servers
167 that have passed the sanity tests are declared _selectable_. From the
168 selectable population the statistics are used by the algorithm described
169 on the link:select.html[Clock Select Algorithm] page to determine a
170 number of _truechimers_ according to Byzantine agreement and correctness
171 principles. From the truechimer population the algorithm described on
172 the link:cluster.html[Clock Cluster Algorithm] page determines a number
173 of _survivors_ on the basis of statistical clustering principles.
175 The algorithms described on the link:prefer.html[Mitigation Rules and
176 the +prefer+ Keyword] page combine the survivor offsets, designate one
177 of them as the _system peer_ and produces the final offset used by the
178 algorithm described on the link:discipline.html[Clock Discipline
179 Algorithm] page to adjust the system clock time and frequency. The clock
180 offset and frequency, are recorded by the +loopstats+ option of the
181 link:monopt.html#filegen[+filegen+] command. For additional details
182 about these algorithms, see the Architecture Briefing on the
183 {millshome}ntp.html[Network Time Synchronization
184 Research Project] page. For additional information on statistical
185 principles and performance metrics, see the link:stats.html[Performance
186 Metrics] page.
188 '''''
190 include::includes/footer.adoc[]