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 use.
NTP was originally designed by David L. Mills of the University of Delaware, who still develops
and maintains it with a team of volunteers.
NTP is intended to synchronize all participating computers to within a few milliseconds of
Coordinated Universal Time.
It uses 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 on port number
123.
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.
As of June 2010, the current protocol is version 4, which is a proposed standard as documented
in RFC 5905.
It is backward compatible with version 3, specified in RFC 1305.
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
at the top.
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 other stratum 2 time sources.
Telecommunication systems use a different definition for clock strata.
Stratum 0 These are high-precision timekeeping devices
such as atomic clocks, GPS clocks or other radio clocks.
They generate a very accurate pulse per second signal that triggers an interrupt and timestamp
on a connected computer.
Stratum 0 devices are also known as reference clocks.
Stratum 1 These are computers whose system clocks are
synchronized to within a few microseconds of their attached stratum 0 devices.
Stratum 1 servers may peer with other stratum 1 servers for sanity checking and backup.
They are also referred to as primary time servers.
Stratum 2 These are computers that are synchronized
over a network to stratum 1 servers.
Often a stratum 2 computer will query several stratum 1 servers.
Stratum 2 computers may also peer with other stratum 2 computers to provide more stable
and robust time for all devices in the peer group.
Stratum 3 These are computers that are synchronized
to stratum 2 servers.
They employ exactly the same algorithms for peering and data sampling as stratum 2, and
can themselves act as servers for stratum 4 computers, and so on.
Only strata 0 to 15 are valid; 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.
Timestamps The 64-bit timestamps used by NTP consist
of a 32-bit part for seconds and a 32-bit part for fractional second, giving a time
scale that rolls over every 232 seconds and a theoretical resolution of 2−32 seconds.
NTP uses an epoch of January 1, 1900 so the first roll over will be in 2036.
Future versions of NTP may extend the time representation to 128 bits: 64 bits for the
second and 64 bits for the fractional-second.
The current NTPv4 format has support for Era Number and Era Offset, that when used properly
should aid fixing date rollover issues.
According to Mills, "the 64 bit value for the fraction is enough to resolve the amount
of time it takes a photon to pass an electron at the speed of light.
The 64 bit second value is enough to provide unambiguous time representation until the
universe goes dim."
Clock synchronization algorithm A typical NTP client will regularly poll three
or more servers on diverse networks.
To synchronize its clock with a remote server, the client must compute the round-trip delay
time and the offset.
The round-trip delay δ is computed as
where t0 is the client's timestamp of the request
packet transmission, t1 is the server's timestamp of the request
packet reception, t2 is the server's timestamp of the response
packet transmission and t3 is the client's timestamp of the response
packet reception.
Therefore t3 − t0 is the time elapsed on the client
side between the emission of the request packet and the reception of the response packet and
t2 − t1 is the time the server waited before sending the answer.
The offset θ is given by
The calculated δ 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 gradually reduce the offset, creating a feedback loop.
The synchronization is correct 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, there will be a systematic bias of
half the difference between the forward and backward travel times.
Software implementations Reference implementation
The NTP reference implementation, along with the protocol, has been continuously developed
for over 20 years.
Backwards compatibility has been maintained as new features have been added.
It contains several sensitive algorithms, especially to discipline the clock, that can
misbehave when synchronized to servers that use different algorithms.
The software has been ported to almost every computing platform, including personal computers.
It runs as a daemon called ntpd under unix or as a service under Windows.
Reference clocks are supported and their offsets are filtered and analysed in the same way
as remote servers, although they are usually polled more frequently.
SNTP A less complex implementation of NTP, using
the same protocol but without requiring the storage of state over extended periods of
time, is known as the Simple Network Time Protocol.
It is used in some embedded devices and in applications where high accuracy timing is
not required.
Windows Time service All Microsoft Windows versions since Windows
2000 and Windows XP include the Windows Time service, which has the ability to synchronize
the computer clock to an NTP server.
The W32Time service was originally implemented for the purpose of the Kerberos version 5
authentication protocol, which required time to be within not more than 5 minutes of the
correct value.
The version in Windows 2000 and Windows XP only implements Simple NTP, and violates several
aspects of the NTP version 3 standard.
Beginning with Windows Server 2003 and Windows Vista, a compliant implementation of full
NTP is included.
Microsoft says that the W32Time service cannot reliably maintain sync time to the range of
1 to 2 seconds.
If higher accuracy is desired, Microsoft recommends to use a different NTP implementation.
Leap seconds On the day of a leap second event, ntpd receives
notification from either a configuration file, an attached reference clock or a remote server.
Because of the requirement that time must appear to be monotonically increasing, a leap
second is inserted with the sequence 23:59:59, 23:59:60, 00:00:00.
Although the clock is actually halted during the event, any processes that query the system
time cause it to increase by a tiny amount, preserving the order of events.
If it should ever become necessary, a leap second would be deleted by skipping 23:59:59.
Security concerns NTP servers are susceptible to man-in-the-middle
attacks unless packets are cryptographically signed for authentication.
The computational overhead involved can make this impractical on busy servers, particularly
during denial of service attacks.
Only a few security problems have been identified in the reference implementation of the NTP
codebase in its 25+ year history.
The protocol has been undergoing revision and review over its entire history.
As of January 2011, there are no security revisions in the NTP specification and no
reports at CERT.
The current codebase for the reference implementation has been undergoing security audits from several
sources for several years now, and there are no known high-risk vulnerabilities in the
current released software.
Several NTP server misuse and abuse practices exist which cause damage or degradation to
a Network Time Protocol server.
NTP has been used in distributed denial of service attacks.
A small query is sent to an NTP server with the return address spoofed to be the target
address.
Similar to the DNS amplification attack, the server responds with a much larger reply that
allows an attacker to substantially increase the amount of data being sent to the target.
To avoid participating in an attack, servers can be configured to ignore external queries,
or they can be upgraded to version 4.2.7p26 or later.
See also
Allan variance International Atomic Time
NITZ OpenNTPD
Ntpdate NTP pool
DAYTIME ICMP Timestamp
ICMP Timestamp Reply Precision Time Protocol
Time Protocol Notes
References
Further reading RFC 958, RFC 1059, RFC 1119, RFC 1305, RFC
1361, RFC 1769, RFC 2030, RFC 4330, RFC 5905, RFC 5906, RFC 5907, RFC 5908
External links Official website
IETF NTP working group David Mills' NTP project page
Time and NTP paper NTP Survey 2005
Current NIST leap seconds file compatible with ntpd