Network Time Protocol

At first glance, synchronizing the time of two or more machines would seem to be a trivial matter. You just have one machine ask another machine, which is presumed to have a more accurate notion of what time it is, to provide the current time. Then you set the time of the local machine based on the answer you receive. And if your needs are such that "within a few seconds" of accuracy are acceptable, then such a simplistic approach would be more then adequate. But what if your needs are more stringent; say, requiring accuracy to within a fraction of a second, or even within milliseconds? Such a simplistic approach fails because it simply does not take into consideration a multitude of variables having to do with the effect of the synchronization process itself -specifically, the time it takes- on the timestamp received from the queried server. For example, how many milliseconds did it take for your machine to retrieve the current time from your system's clock? How long did it take to send a message over the Internet to the target time server? How long did it take the target server to process your request, and send you a reply? For you to set your clock with the highest degree of accuracy, each of these intervals must be measured and quantified via the best possible means. And by the way, how accurate is that timestamp returned by the target server? Is it comparable to other available standard time servers? And for the purposes of continued accuracy in your own application, how accurate is your own clock over a given period of time?

Who has a need for precision time?

  • Distributed database transaction journalling and logging
  • Stock market buy and sell orders
  • Secure document timestamps (with cryptographic certification)
  • Aviation traffic control and position reporting
  • Radio and TV programming launch and monitoring
  • Intruder detection, location and reporting
  • Multimedia synchronization for real-time teleconferencing
  • Interactive simulation event synchronization and ordering
  • Network monitoring, measurement and control
  • Early detection of failing network infrastructure devices and air
  • conditioning equipment
  • Differentiated services traffic engineering
  • Distributed network gaming and training

What is NTP?

NTP is a protocol built on top of TCP/IP that assures accurate local timekeeping with reference to radio, atomic or other clocks located on the Internet. This protocol is capable of synchronizing distributed clocks within milliseconds over long time periods. NTP software is available on almost every operating system today and is part of every Windows XP installation. There are approxiamately 1 million NTP servers deployed around the world. NTP has been in use and developed for the last 20 years and is currently in Version 4. NTP provides for accuracies of tens of milliseconds across WAN's, sub millisecond accuracy on LAN's, and submicroseconds using a precision time source such as a cesium oscillator.

NTP uses the UDP protocol on port 123 to communicate between clients and servers. Attempts are tried at designated intervals until the server responds. The interval depends on a number of factors, and ranges from about once a minute to once every 17 minutes. Using UDP prevents retries from using up network bandwidth if a time server with a large number of clients goes down.

NTP requires little resource overhead. This allows NTP to be easily deployed on servers hosting other services, even if the servers are heavily loaded. Even a single processor NTP server can serve hundreds or even thousands of clients using only a few percent of its CPU capacity. If the server is a broadcast or multicast server, even fewer resources are required.

The bandwidth requirements for NTP are also minimal. Unencrypted NTP Ethernet packets are 90 bytes long (76 bytes long at the IP layer). A broadcast server sends out a packet about every 64 seconds. A non-broadcast client/server requires 2 packets per transaction. When first started, transactions occur about once per minute, increasing gradually to once per 17 minutes under normal conditions. Poorly synchronized clients will tend to poll more often than well synchronized clients. In NTP version 4 implementations, the minimum and maximum intervals can be extended beyond these limits, if necessary.

Architecture

NTP works on a hierarchical model in which a small number of servers give time to a large number of clients. The clients on each level, or stratum, are in turn, potential servers to an even larger number of clients of a higher numbered stratum. Stratum numbers increase from the primary (stratum 1) servers to the low numbered strata at the leaves of the tree. Clients can use time information from multiple servers to automatically determine the best source of time and prevent bad time sources from corrupting their own time.

Servers that are directly connected to a reference clock are termed stratum 1 servers. A reference clock connected to a stratum 1 server is referred to as a stratum 0 server. Clients never communicate directly with a stratum 0 server; they always go through a stratum 1 server synchronized to a stratum 0 server. However, some vendors sell reference clocks (stratum 0 servers) which include an external network interface that acts as a stratum 1 server.

Stratum 2 servers receive their time from one or more stratum 1 time servers. If they serve time to clients, they are also referred to as stratum 2 servers, and the clients they serve are stratum 3 clients. This continues to higher numbered strata. The maximum NTP stratum number for a client is 15; however, in practice it is rare to find clients with stratum numbers above 4 or 5 in most real-world configurations. Stratum 2 time servers are not significantly less accurate that stratum 1 time servers. Using an accurate stratum 2 server which is synced to several time sources may allow for better accuracy than using an overloaded or inaccurate stratum 1 server that is not configured to communicate with other time sources. Clients and servers operate in a master/slave relationship. Reliability is assued by redundant servers and diverse network paths. The system clock is disciplined in time and frequency using an adaptive algorithm responsive to network time jitter and clock oscillator frequency wander.

Relationships

The relationship between NTP servers and clients can be configured to operate in several ways. Computers using NTP can operate in different modes with respect to different machines. For instance, a single machine could be a client of a machine with a lower stratum number, while being a peer to a machine on the same stratum, and a broadcast server to a number of clients at a higher stratum number.

  • Server -An NTP server serves time to clients. Clients send a request to the server and the server sends back a time stamped response, along with information such as its accuracy and stratum.
  • Client - An NTP client gets time responses from an NTP server or servers, and uses the information to calibrate its clock. This consists of the client determining how far its clock is off and adjusting its time to match that of the server. The maximum error is determined based on the round-trip time for the packet to be received.
  • Peer - An NTP peer is a member of a group of NTP servers that are tightly coupled. In a group of two peers, at any given time, the most accurate peer is acting as a server and the other peers are acting as clients. The result is that peer groups will have closely synchronized times without requiring a single server to be specified.
  • Broadcast/multicast server - An NTP server can also operate in a broadcast or multicast mode. Both work similarly; broadcast servers send periodic time updates to a broadcast address, while multicast servers send periodic updates to a multicast address. Using broadcast packets can greatly reduce the NTP traffic on a network, especially for a network with many NTP clients.
  • Broadcast/multicast client - An NTP broadcast or multicast client listens for NTP packets on a broadcast or multicast address. When the first packet is received, it attempts to quantify the delay to the server in order to better quantify the correct time from later broadcasts. This is accomplished by a series of brief interchanges where the client and server act as a regular (non-broadcast) NTP client and server. Once these interchanges occur, the client has an idea of the network delay and thereafter can estimate the time based only on broadcast packets. If this interchange is not desirable, it can be disabled using NTP?s access control features. The -r option can be used when xntpd is started to hardwire a delay if the interchange fails because of access control issues or other problems.

Configuration

XNTPD is the daemon that's run on Unix systems and implements the NTP protocol. It is easy to configure and can be running in less than 5 minutes. In fact, in many of the new linux distros, it is preconfigured and ready to go. Below is an example of an ntp.conf file.

#server nist1.datum.com prefer
#server time-b.nist.gov
server time-b.timefreq.bldrdoc.gov prefer
server clock.isc.org
server time-a.nist.gov

driftfile /var/db/ntp.drift

#restrict default nomodify notrust
logconfig       all
logfile         /var/log/xntpd

setvar info_url=http://www.ringofsaturn.com/?Include=serverinfo.php default
setvar admin_contact=ntp@ringofsaturn.com    default
setvar access_policy="Internal Access Only"    default

In this case, this is actually more than is needed to successfully get xntpd working. The first section defines the servers that xntpd will use for time synchronization. The driftfile is basically a log file and contains something like:

[tethys]:/home/rnejdl> cat /var/db/ntp.drift
-26.520
[tethys]:/home/rnejdl>

The rest of the file defines logging and then SNMP information. Once that is setup, simply start the daemon. In FreeBSD's case, add xntpd_enable="YES" to your /etc/rc.conf file and then run /etc/rc.d/ntpd as root.

[tethys]:/home/rnejdl> sudo /etc/rc.d/ntpd start
Starting ntpd.
[tethys]:/home/rnejdl> 

Monitoring

The /usr/sbin/ntpq program allows querying the state of the NTP daemon on a local or remote machine. Using ntpq, an administrator can check the configuration of a remote host. Below is an example usage:

[tethys]:/home/rnejdl> ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*time-A.timefreq .ACTS.           1 u  152 1024  377   43.527  -11.093   3.982
+clock.isc.org   204.123.2.5      2 u  230 1024  377   67.958   -7.729   0.071
 time-a.nist.gov .ACTS.           1 u  323 1024  377   58.705  994.866 999.084
[tethys]:/home/rnejdl>

Remote is the first 15 characters of the remote server's name, prefixed by a character that indicates the status of the remote server:

  • space (reject) The peer is discarded as unreachable, synchronized to this server (synch loop) or outrageous synchronization distance.
  • x (falsetick) The peer is discarded by the intersection algorithm as a falseticker.
  • . (excess) The peer is discarded as not among the first ten peers sorted by synchronization distance and so is probably a poor candidate for further consideration.
  • - (outlyer) The peer is discarded by the clustering algorithm as an outlyer.
  • + (candidate) The peer is a survivor and a candidate for the combining algorithm.
  • # (selected) The peer is a survivor, but not among the first six peers sorted by synchronization distance. If the association is ephemeral, it may be demobilized to conserve resources.
  • * (peer) The peer has been declared the system peer and lends its variables to the system variables.
  • o ((pps.peer)) The peer has been declared the system peer and lends its variables to the system variables. However, the actual system synchronization is derived from a pulse-per-second (PPS) signal, either indirectly via the PPS reference clock driver or directly via kernel interface.

Refid is the remote server's current source for time. If this is 0.0.0.0 or something similar, you are not getting time service from the remote server.

St is the remote server's current stratum level. If this is 16, you are not getting time service from the remote server.

When is the number of seconds since a time service reply has been received from the remote server.

Poll is the number of seconds between polls of the remote server.

Reach is an octal bitmap of the results of the last eight polls of the remote server. A value of 377 means that the last eight attempts were successful; a value of 0 means that the last eight attempts were unsuccessful (you are not getting time service from the remote server).

Delay is the number of milliseconds it is taking for NTP packets to make the round-trip from your host to the remote server and back, and is an important factor used by NTP in selecting the "best" server. This is the reason you want to pick servers that are close to you.

Offset is the difference in milliseconds between the clocks in your host and the remote server.

Jitter (or disp) is the "dispersion" in milliseconds of successive time values from the remote server. It is a measure of the stability (time-wise) of the network path to the remote server, and is also an important factor used by NTP in selecting the "best" server.

In looking at the example again, you can see that time-a.nist.gov has so much jitter that it is unusable. This peer should be replaced in the configuration file with a different choice. After replacing time-a.nist.gov with time-b.nist.gov and restarting the daemon, I now have the following:

[tethys]:/home/rnejdl> ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*time-A.timefreq .ACTS.           1 u   44   64   37   40.146    7.636  38.966
+clock.isc.org   204.123.2.5      2 u   46  512   37   70.350    5.603   3.131
+time-b.nist.gov .ACTS.           1 u   47   64   37   55.306    6.988   2.555
[tethys]:/home/rnejdl>

Other Tools

The ntpdc -c loopinfo will display how far off the system time is in seconds, based upon the last time the remote server was contacted.

[tethys]:/home/rnejdl> ntpdc -c loopinfo
offset:               0.001484 s
frequency:            -24.456 ppm
poll adjust:          6
watchdog timer:       104 s
[tethys]:/home/rnejdl>

ntpdc -c kerninfo will display the current remaining correction.

[tethys]:/home/rnejdl> ntpdc -c kerninfo
pll offset:           0.00130076 s
pll frequency:        -24.456 ppm
maximum error:        0.119675 s
estimated error:      0.019441 s
status:               2001  pll nano
pll time constant:    6
precision:            1e-09 s
frequency tolerance:  496 ppm
[tethys]:/home/rnejdl>

A slightly different version of ntpdc -c kerninfo is ntptime

[tethys]:/home/rnejdl> ntptime
ntp_gettime() returns code 0 (OK)
  time c67bb92e.a4e79a70  Sun, Jul 10 2005 10:11:42.644, (.644159325),
  maximum error 131675 us, estimated error 19441 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 1270.610 us, frequency -24.456 ppm, interval 1 s,
  maximum error 131675 us, estimated error 19441 us,
  status 0x2001 (PLL,NANO),
  time constant 6, precision 0.001 us, tolerance 496 ppm,
[tethys]:/home/rnejdl>

Yet another way to see how well NTP is working is with the ntpdate -d command. This will contact an NTP server and determine the time difference but not change your system's time.

[tethys]:/home/rnejdl> ntpdate -d time-b.nist.gov
10 Jul 10:12:23 ntpdate[47684]: ntpdate 4.2.0-a Sun Jun 26 08:37:00 CDT 2005 (1)
Looking for host time-b.nist.gov and service ntp
host found : time-b.nist.gov
transmit(129.6.15.29)
receive(129.6.15.29)
transmit(129.6.15.29)
receive(129.6.15.29)
transmit(129.6.15.29)
receive(129.6.15.29)
transmit(129.6.15.29)
receive(129.6.15.29)
transmit(129.6.15.29)
server 129.6.15.29, port 123
stratum 1, precision -30, leap 00, trust 000
refid [ACTS], delay 0.08467, dispersion 0.00159
transmitted 4, in filter 4
reference time:    c67bb954.433dc9fe  Sun, Jul 10 2005 10:12:20.262
originate timestamp: c67bb957.dcc0fffe  Sun, Jul 10 2005 10:12:23.862
transmit timestamp:  c67bb957.7ed1e927  Sun, Jul 10 2005 10:12:23.495
filter delay:  0.10652  0.08763  0.08588  0.08467
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.329813 0.338742 0.338011 0.337382
         0.000000 0.000000 0.000000 0.000000
delay 0.08467, dispersion 0.00159
offset 0.337382

10 Jul 10:12:23 ntpdate[47684]: adjust time server 129.6.15.29 offset 0.337382 sec
[tethys]:/home/rnejdl>

If you want actually watch the system synchronize you can use ntptrace.

[tethys]:/home/rnejdl> sudo ntptrace time-b.nist.gov
time-b.nist.gov: stratum 1, offset 0.000000, root distance 0.001300, refid 'ACTS'
[tethys]:/home/rnejdl>

If you need your system time synchronized immediately you can use the ntpdate remote-servername to force a synchronization. This should not be used with xntpd.

[tethys]:/home/rnejdl> sudo ntpdate 132.236.56.250 13 Nov 14:56:28 ntpdate[29676]: adjust time server 132.236.56.250 offset -0.003151 sec [tethys]:/home/rnejdl>

Finding a Time Server

The complete lists are available from the following links. For detailed information about a server click the hostname in the list.

Use ISC's WebSearch to search the Time Server Lists based on various criteria.

NTP RFC's

RFCs related to NTP and Network Time Synchronization
Number Title Author or Ed.
RFC-2783 Pulse-Per-Second API for UNIX-like Operating Systems, Version 1.0 J. Mogul, D. Mills, J. Brittenson, J. Stone, U. Windl
(March 2000)
RFC-2030 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI

Obsoletes RFC-1769

D. Mills
(October 1996)
RFC-1769 Simple Network Time Protocol (SNTP)

Obsoletes RFC-1361
Obsoleted by RFC-2030

D. Mills
(March 1995)
RFC-1708 NTP PICS PROFORMA - For the Network Time Protocol Version 3 D. Gowin
(October 1994)
RFC-1589 A Kernel Model for Precision Timekeeping D. Mills
(March 1994)
RFC-1361 Simple Network Time Protocol (SNTP)

Obsoleted by RFC-1769

D. Mills
(August 1992)
RFC-1305 Network Time Protocol (Version 3) Specification, Implementation

Obsoletes RFC-958, RFC-1059, RFC-1119

David L. Mills
(March 1992)
RFC-1165 Network Time Protocol (NTP) over the OSI Remote Operations Service J. Crowcroft, J. P. Onions
(June 1990)
RFC-1129 Internet Time Synchronization: The Network Time Protocol D. L. Mills
(October 1989)
RFC-1059 Network Time Protocol (version 1) specification and implementation

Obsoletes RFC-958
Obsoleted by RFC-1119, RFC-1305

D. L. Mills
(July 1988)
RFC-958 Network Time Protocol (NTP)

Obsoleted by RFC-1059, RFC-1119, RFC-1305

D. L. Mills
(September 1985)
RFC-868 Time Protocol J. Postel, K. Harrenstien
(May 1983)
RFC-867 Daytime Protocol J. Postel
(May 1983)
}