The Full Wiki

Time Protocol: Wikis


Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.


(Redirected to Network Time Protocol article)

From Wikipedia, the free encyclopedia

The Network Time Protocol (NTP) is a protocol for synchronizing the clocks of computer systems over packet-switched, variable-latency data networks. NTP uses UDP on port 123 as its transport layer. It is designed particularly to resist the effects of variable latency by using a jitter buffer. NTP also refers to a reference software implementation that is distributed by the NTP Public Services Project.

NTP is one of the oldest Internet protocols still in use (since before 1985). NTP was originally designed by Dave Mills of the University of Delaware, who still maintains it, along with a team of volunteers.

NTP is not related to the simpler DAYTIME (RFC 867) and TIME (RFC 868) protocols.

The Internet Protocol Suite
Application Layer
BGP · DHCP · DNS · FTP · GTP · HTTP · IMAP · IRC · Megaco · MGCP · NNTP · NTP · POP · RIP · RPC · RTP · RTSP · SDP · SIP · SMTP · SNMP · SOAP · SSH · Telnet · TLS/SSL · XMPP · (more)
Transport Layer
TCP · UDP · DCCP · SCTP · RSVP · ECN · (more)
Internet Layer
IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec · (more)
Link Layer
ARP/InARP · NDP · OSPF · Tunnels (L2TP) · PPP · Media Access Control (Ethernet, DSL, ISDN, FDDI) · (more)



NTP uses Marzullo's algorithm, and includes support for features such as leap seconds. NTPv4 can usually maintain time to within 10 milliseconds (1/100 s) over the public Internet, and can achieve accuracies of 200 microseconds (1/5000 s) or better in local area networks under ideal conditions.

NTP provides Coordinated Universal Time (UTC). No information about time zones or daylight saving time is transmitted; this information is outside its scope and must be obtained separately. In isolated LANs, NTP could in principle be used to distribute a different time scale (e.g. local zone time), but this is uncommon.

The operational details of NTP are specified in RFC 778, RFC 891, RFC 956, and RFC 1305. The current reference implementation is version 4 (NTPv4);[1] however, as of 2005, only versions up to 3 (1992) have been documented in RFCs. The Internet Engineering Task Force NTP Working Group[2] standardizes the work of the NTP community since publication of RFC 1305.

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 (SNTP). It is used in some embedded devices and in applications where high accuracy timing is not required (RFC 1361, RFC 1769, RFC 2030, and RFC 4330).

NTP software implementations



For modern Unix systems, the NTP client is implemented as a daemon process that runs continuously in user space (ntpd). Because of sensitivity to timing, however, it is important to have the standard NTP clock phase-locked loop implemented in kernel space. All recent versions of Linux, BSD, Mac OS X and Solaris are implemented in this manner.

Microsoft Windows

All Microsoft Windows versions since Windows 2000 include the Windows Time Service,[3] which has the ability to sync the computer clock to an NTP server. However, the version in Windows 2000 only implements Simple NTP, and violates several aspects of the NTP version 3 standard.[4] Beginning with Windows Server 2003, the Microsoft documentation states that Windows Time Service implements the full NTPv3 protocol[5] as specified in RFC 1305.

However, the Windows Time Service cannot maintain the system time more accurately than about a 1-2 second range. Microsoft "[does] not guarantee and [does] not support the accuracy of the W32Time service between nodes on a network. The W32Time service is not a full-featured NTP solution that meets time-sensitive application needs."[6]

The reference implementation of NTP can be used on Microsoft Windows systems.[7]

Clock strata

Yellow arrows indicate a direct connection; red arrows indicate a network connection.
The U.S. Naval Observatory Alternate Master Clock at Schriever AFB (Colorado) is a Stratum-0 source for NTP

NTP uses a hierarchical, semi-layered system of levels of clock sources, each level of this hierarchy is termed a stratum and assigned a layer number starting with 0 (zero) at the top. The stratum level defines its distance from the reference clock and exists to prevent cyclical dependencies in the hierarchy. It is important to note that the stratum is not an indication of quality or reliability, it is quite common to find "stratum 3" time sources that are higher quality than other "stratum 2" time sources. This definition of "stratum" is also different from the notion of clock strata used in telecommunication systems.

Stratum 0
These are devices such as atomic (caesium, rubidium) clocks, GPS clocks or other radio clocks. Stratum-0 devices are traditionally not attached to the network; instead they are locally connected to computers (e.g., via an RS-232 connection using a Pulse per second signal).
Stratum 1
These are computers attached to Stratum 0 devices. Normally they act as servers for timing requests from Stratum 2 servers via NTP. These computers are also referred to as time servers. Many Stratum 1 servers (for NTP v3 and earlier versions) may not actually be operating with Stratum 1 precision. As the NTP protocol is developed, it will become less and less possible for misleading Stratum 1 servers to run — instead the protocol would automatically bump the server Stratum level down accordingly.
Stratum 2
These are computers that send NTP requests to Stratum 1 servers. Normally a Stratum 2 computer will reference a number of Stratum 1 servers and use the NTP algorithm to gather the best data sample, dropping any Stratum 1 servers that seem obviously wrong. Stratum 2 computers will peer with other Stratum 2 computers to provide more stable and robust time for all devices in the peer group. Stratum 2 computers normally act as servers for Stratum 3 NTP requests.
Stratum 3
These computers employ exactly the same NTP functions of peering and data sampling as Stratum 2, and can themselves act as servers for lower strata, potentially up to 16 levels. NTP (depending on what version of NTP protocol in use) supports up to 256 strata.

It is hoped that in NTP 5, a protocol still in development, only 8 strata will be permitted. As most NTP clients call on Stratum 2 servers, it is expected that no users will be disadvantaged by the loss of granularity.[citation needed]

NTP timestamps

The 64-bit timestamps used by NTP consist of a 32-bit seconds part and a 32-bit fractional second part, giving NTP a time scale of 232 seconds (136 years) and a theoretical resolution of 2−32 seconds (233 picoseconds).

The NTP timescale wraps around every 232 seconds (136 years). NTP uses an epoch of January 1, 1900, so the first rollover will occur in 2036, well before the familiar UNIX Year 2038 problem.

Implementations should disambiguate NTP time using a knowledge of the approximate time from other sources. Since NTP only works with the differences between timestamps and never their absolute values, the wraparound is invisible as long as the timestamps are within 68 years of each other. This means that the rollover will be invisible for most running systems, since they will have the correct time to within a very small tolerance. However, systems that are starting up need to know the date within no more than 68 years. Given the large allowed error, it is not expected that this is too onerous a requirement. One suggested method is to set the clock to no earlier than the system build date. Many systems use a battery powered hardware clock to avoid this problem.

Even so, future versions of NTP may extend the time representation to 128 bits: 64 bits for the second and 64 bits for the fractional-second.

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."[8] Indeed, 2−64 seconds is about 54 zeptoseconds, and 264 seconds is about 585 billion years.

Security concerns

Only a few security problems have been identified in the reference implementation of the NTP codebase in its 25+ year history.[9][10]

NTP itself has been undergoing revision and review over its entire history; no security vulnerabilities have ever been reported that have been traced to the NTP specification.[11]

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.[12]

See also

Other time synchronization protocols:


Further reading

  • Mills, David L.. Computer Network Time Synchronization: The Network Time Protocol. Taylor & Francis / CRC Press. ISBN 0849358051. 

External links

The Internet Protocol Suite
Application Layer
BGPTemplate:, DHCPTemplate:, DNSTemplate:, FTPTemplate:, GTPTemplate:, HTTPTemplate:, IMAPTemplate:, IRCTemplate:, MegacoTemplate:, MGCPTemplate:, NNTPTemplate:, NTPTemplate:, POPTemplate:, RIPTemplate:, RPCTemplate:, RTPTemplate:, RTSPTemplate:, SDPTemplate:, SIPTemplate:, SMTPTemplate:, SNMPTemplate:, SOAPTemplate:, SSHTemplate:, TelnetTemplate:, TLS/SSLTemplate:, XMPPTemplate:, (more)
Transport Layer
TCPTemplate:, UDPTemplate:, DCCPTemplate:, SCTPTemplate:, RSVPTemplate:, ECNTemplate:, (more)
Internet Layer
IP (IPv4, IPv6)Template:, ICMPTemplate:, ICMPv6Template:, IGMPTemplate:, IPsecTemplate:· (more)
Link Layer
ARPTemplate:, RARPTemplate:, NDPTemplate:, OSPFTemplate:, Tunnels (L2TP)Template:, PPPTemplate:, Media Access Control (Ethernet, MPLS, DSL, ISDN, FDDI)Template:, Device DriversTemplate:, (more)

The TIME service is an Internet protocol defined in RFC 868. Its purpose is to provide a site-independent, machine readable date and time.

TIME can operate over either TCP or UDP. When operating over TCP, a host connects to a server that supports the TIME protocol on TCP port 37. The server then sends the time as a 32-bit unsigned binary number in network byte order representing a number of seconds since 00:00 (midnight) 1 January, 1900 GMT and closes the connection. The host receives the time and closes the connection.

When operating over UDP, the client sends a (typically empty) datagram to UDP port 37. The server responds with a single datagram of length 4 containing the time. There is no connection setup or teardown.

The TIME protocol has been superseded by the Network Time Protocol (NTP).

inetd/xinetd implementation of TIME

On Linux, FreeBSD, and other UNIX-like operating systems a time server is often built into the inetd daemon. The time service is usually not enabled by default. It may be enabled by adding the following lines to the file /etc/inetd.conf

time   stream  tcp     nowait  root    internal
time   dgram   udp     wait    root    internal

and (as root) telling inetd to reload its configuration:

killall -HUP inetd

On OpenBSD, inetd configured to support TIME service by default.

Modern versions of Linux use xinetd instead of inetd. On modern Red Hat Linux systems there are text files /etc/xinetd.d/time or /etc/xinetd.d/time-stream (for TCP version) and /etc/xinetd.d/time-udp or /etc/xinetd.d/time-dgram (for UDP version). Changing the disable parameter to disable = no will enable the service. Restart the service using the service xinetd restart command. Note, if these files don't exist then you may need to install xinetd (yum install xinetd).

See also

External links


Got something to say? Make a comment.
Your name
Your email address