Network Time Protocol

The Network Time Protocol is a networking protocol for clock synchronization between computer systems over packet-switched, variable-latency data networks. In operation since before 1985, NTP is one of the oldest Internet protocols in current use. NTP was designed by David L. Mills of the University of Delaware.
NTP is intended to synchronize participating computers to within a few milliseconds of Coordinated Universal Time. It uses the intersection algorithm, a modified version of Marzullo's algorithm, to select accurate time servers and is designed to mitigate the effects of variable network latency. NTP can usually maintain time to within tens of milliseconds over the public Internet, and can achieve better than one millisecond accuracy in local area networks under ideal conditions. Asymmetric routes and network congestion can cause errors of 100 ms or more.
The protocol is usually described in terms of a client–server model, but can as easily be used in peer-to-peer relationships where both peers consider the other to be a potential time source. Implementations send and receive timestamps using the User Datagram Protocol ; the service is normally on port number 123, and in some modes both sides use this port number. They can also use broadcasting or multicasting, where clients passively listen to time updates after an initial round-trip calibrating exchange. NTP supplies a warning of any impending leap second adjustment, but no information about local time zones or daylight saving time is transmitted.
The current protocol is version 4, which is backward compatible with version 3.

Clock synchronization algorithm

A typical NTP client regularly polls one or more NTP servers. The client must compute its time offset and round-trip delay. Time offset θ is the positive or negative difference in absolute time between the two clocks. It is defined by
and the round-trip delay δ by
where

t₀ is the client's timestamp of the request packet transmission,
t₁ is the server's timestamp of the request packet reception,
t₂ is the server's timestamp of the response packet transmission and
t₃ is the client's timestamp of the response packet reception.

To derive the expression for the offset, note that for the request packet,
and for the response packet,
Solving for θ yields the definition of the time offset.
The values for θ and δ are passed through filters and subjected to statistical analysis. Outliers are discarded and an estimate of time offset is derived from the best three remaining candidates. The clock frequency is then adjusted to reduce the offset gradually, creating a feedback loop.
Accurate synchronization is achieved when both the incoming and outgoing routes between the client and the server have symmetrical nominal delay. If the routes do not have a common nominal delay, a systematic bias exists of half the difference between the forward and backward travel times. A number of approaches have been proposed to measure asymmetry, but among practical implementations only chrony seems to have one included.

History

In 1979, network time synchronization technology was used in what was possibly the first public demonstration of Internet services running over a trans-Atlantic satellite network, at the National Computer Conference in New York. The technology was later described in the 1981 Internet Engineering Note 173 and a public protocol was developed from it that was documented in. The technology was first deployed in a local area network as part of the Hello routing protocol and implemented in the Fuzzball router, an experimental operating system used in network prototyping, where it ran for many years.
Other related network tools were available both then and now. They include the Daytime and Time protocols for recording the time of events, as well as the ICMP Timestamp messages and IP Timestamp option. More complete synchronization systems, although lacking NTP's data analysis and clock disciplining algorithms, include the Unix daemon timed, which uses an election algorithm to appoint a server for all the clients; and the Digital Time Synchronization Service, which uses a hierarchy of servers similar to the NTP stratum model.
In 1985, NTP version 0 was implemented in both Fuzzball and Unix, and the NTP packet header and round-trip delay and offset calculations, which have persisted into NTPv4, were documented in. Despite the relatively slow computers and networks available at the time, accuracy of better than 100 milliseconds was usually obtained on Atlantic spanning links, with accuracy of tens of milliseconds on Ethernet networks.
In 1988, a much more complete specification of the NTPv1 protocol, with associated algorithms, was published in. It drew on the experimental results and clock filter algorithm documented in and was the first version to describe the client–server and peer-to-peer modes. In 1991, the NTPv1 architecture, protocol and algorithms were brought to the attention of a wider engineering community with the publication of an article by David L. Mills in the IEEE Transactions on Communications.
In 1989, was published defining NTPv2 by means of a state machine, with pseudocode to describe its operation. It introduced a management protocol and cryptographic authentication scheme which have both survived into NTPv4, along with the bulk of the algorithm. However the design of NTPv2 was criticized for lacking formal correctness by the DTSS community, and the clock selection procedure was modified to incorporate Marzullo's algorithm for NTPv3 onwards.
In 1992, defined NTPv3. The RFC included an analysis of all sources of error, from the reference clock down to the final client, which enabled the calculation of a metric that helps choose the best server where several candidates appear to disagree. Broadcast mode was introduced.
In subsequent years, as new features were added and algorithm improvements were made, it became apparent that a new protocol version was required. In 2010, was published containing a proposed specification for NTPv4. Following the retirement of Mills from the University of Delaware, the reference implementation is currently maintained as an open source project led by Harlan Stenn. On the IANA side, a ntp work group is in charge of reviewing proposed drafts.
The protocol has significantly progressed since NTPv4., three RFC documents describing updates to the protocol have been published, not counting the numerous peripheral standards such as Network Time Security. Mills had mentioned plans for a "NTPv5" on his page, but one was never published. An unrelated draft termed "NTPv5" by M. Lichvar of chrony was initiated in 2020 and includes security, accuracy, and scaling changes.

SNTP

As NTP replaced the old Time Protocol, some use cases nevertheless found the full protocol too complicated. In 1992, Simple Network Time Protocol was defined to fill this niche. The SNTPv3 standard describes a way to use NTPv3 such that no storage of state over an extended period is needed. The topology becomes essentially the same as with the Time Protocol, as only one server is used. In 1996, SNTP was updated to SNTPv4, with some features of the then-in-development NTPv4. SNTPv4 was merged into the main NTPv4 standard in 2010.
SNTP is fully interoperable with NTP since it does not define a new protocol, as it utilizes the same packet format and port as NTP, ensuring compatibility with NTP servers. However, client/server will lack the complex algorithms required to filter network jitter, analyze clock drift, or cross-reference multiple time sources. This makes it suitable for IoT devices and basic hardware that require "good enough" time without the overhead of a full NTP application stack.
An SNTP client typically operates by querying a single server and applying the received time directly to the local clock. However, the simple algorithms provide times of reduced accuracy and thus it is inadvisable to sync time from an SNTP source. However, RFC 5905 notes that because the additional complexity of the full on-wire protocol is minimal, full implementation is encouraged even for simple clients.

Clock strata

NTP uses a hierarchical, semi-layered system of time sources. Each level of this hierarchy is termed a stratum and is assigned a number starting with zero for the reference clock at the top. A server synchronized to a stratum n server runs at stratum n + 1. The number represents the distance from the reference clock and is used to prevent cyclical dependencies in the hierarchy. Stratum is not always an indication of quality or reliability; it is common to find stratum 3 time sources that are higher quality than some stratum 2 time sources. Brief descriptions of strata 0, 1, 2 and 3 are provided below.
; Stratum 0
; Stratum 1
; Stratum 2
; Stratum 3
The upper limit for stratum is 15; stratum 16 is used to indicate that a device is unsynchronized. The NTP algorithms on each computer interact to construct a Bellman–Ford shortest-path spanning tree, to minimize the accumulated round-trip delay to the stratum 1 servers for all the clients.
In addition to stratum, the protocol is able to identify the synchronization source for each server in terms of a reference identifier.

Refid	Clock Source
GOES	Geostationary Operational Environmental Satellite
GPS	Global Positioning System
GAL	Galileo Positioning System
PPS	Generic pulse-per-second
IRIG	Inter-Range Instrumentation Group
WWVB	LF Radio WWVB Fort Collins, Colorado 60 kHz
DCF/PZF	LF Radio DCF77 Mainflingen, DE 77.5 kHz
HBG	LF Radio HBG Prangins, HB 75 kHz
MSF	LF Radio MSF Anthorn, UK 60 kHz
JJY	LF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz
LORC	MF Radio Loran-C station, 100 kHz
TDF	MF Radio Allouis, FR 162 kHz
CHU	HF Radio CHU Ottawa, Ontario
WWV	HF Radio WWV Fort Collins, Colorado
WWVH	HF Radio WWVH Kauai, Hawaii
NIST	NIST telephone modem
ACTS	NIST telephone modem
USNO	USNO telephone modem
PTB	German PTB time standard telephone modem
MRS	Multi Reference Sources
GOOG	Google Refid used by Google NTP servers as time4.google.com

For servers on stratum 2 and below, the refid is an encoded form of the upstream time server's IP address. For IPv4, this is simply the 32-bit address; for IPv6, it would be the first 32 bits of the MD5 hash of the source address. Refids serve to detect and prevent timing loops to the first degree.
The refid field is filled with status words in the case of kiss-o'-death packets, which tell the client to stop sending requests so that the server can rest. Some examples are INIT, STEP, and RATE. The program output may additionally use codes not transmitted in the packet to indicate error, such as XFAC to indicate a network disconnection.
The IANA maintains a registry for refid source names and KoD codes. Informal assignments can still appear.