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

• 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> 

[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>

[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>

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

[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>

[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>

[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>

[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>