Controlling the Time

Some of the computers in Figure One synchronize to more than one NTP server. For instance, the Stratum 3 laptop refers to three Stratum 2 servers, whereas the desktop system to its right synchronizes to just one server. The option for redundancy provides automatic backup in case one NTP server becomes unavailable. It can also serve as a sanity check: if one server begins delivering wildly inaccurate times, NTP can detect the inconguity and discard the time signals from the “false ticker.”

In practice, if you maintain an entire network of computers, you’re likely to set aside one or two computers to synchronize with one or more upstream NTP servers. You’ll then configure your remaining systems to synchronize to your network’s primary NTP server (s). The result is that all of your networks’ computers’ clocks will be set to within a tiny fraction of a second of each other, and all of these computers’ clocks will be set to within a larger (but still small) fraction of a second of other computers that set their clocks via NTP.

At first, you might think that network time setting would be simple: One computer asks another for the time, the second computer replies, and the first sets its clock appropriately. Unfortunately, it’s not that simple. The problem is that packets take time to traverse a network. If a time protocol fails to take this delay into account, the times of client systems will be inaccurate. In a tiered system such as NTP, this inaccuracy builds the further one gets from the original time source. NTP solves this problem by using back-and-forth exchanges that enable the software to determine the round-trip delay and other related timing issues of the network connection. NTP can then compensate for the network delays, arriving at a very accurate time — assuming the upstream NTP server’s time is accurate, of course.

One quirk of NTP is that the most common NTP software for Linux functions as both a client and a server. The intent is for the software to be able to synchronize its time and then deliver its own time to other systems. The Stratum 1 and 2 computers in Figure One operate in this dual mode. However, even if the computer won’t be functioning as an NTP server to NTP clients, it’s common practice to install the entire NTP server package; you simply won’t use its server features.

One reason for running the full NTP package even on clients is that this package runs in the background and slews your clock– that is, it changes the rate at which the clock runs. In fact, if your clock is off by a couple of seconds when NTP starts, rather than reset the clock in a quick, wholesale operation, NTP slews your clock so that it reaches the correct time in a few hours or days, and then slews the clock so that it maintains the correct time. This method of operation ensures that clock-setting operations don’t disrupt time-dependent software, such as the cron daemon.

Locating an Upstream NTP Server

One of the first things you should do when planning an NTP installation is to locate one or more appropriate NTP servers. For networks of under about 100 computers, you should use a Stratum 2 or lower server; the Stratum 1 servers should be accessed only by computers that themselves deliver the time to hundreds or more computers. You can locate an appropriate server in several ways:

*Check with your ISP or your organization’s networking department. An appropriate server may exist close to you in a network sense, and this proximity improves the accuracy of the time signal.

*Consult http://ntp.isc.org/bin/view/Servers/WebHome, which hosts lists of public Stratum 1 and 2 servers. Be sure to follow any special instructions provided with the descriptions, since many NTP server operators like to be notified of your use of their servers as a matter of courtesy.

*Check your Linux distribution’s documentation. Some distribution maintainers run NTP servers for their customers. These are generally poor choices because they’re likely to be located far away from you in a network sense, but you might luck out on that score.

The ideal NTP server is close to you. This distance is measured in network terms, though, not in geographic miles. For instance, if you’re in Dayton Ohio, you might think an NTP server in Cincinnati (a few miles away) would be a good choice, but if your network traffic to Cincinnati is routed via Los Angeles, you might be better off using an NTP server located in the City of Angels! A quick test is to use the ping program and note the packet return times from the servers you’re considering. The shorter the time the better. The traceroute program is another useful diagnostic tool. It returns information on the number of network hops between you and a target computer; the fewer the hops, the better.

To begin, you should locate two or three candidate servers. You can then install the NTP software on your network’s primary NTP server computer and configure it.

Configuring a Network’s NTP Server

Your NTP server need not be a powerful system. Unless it serves many thousands of computers, NTP doesn’t put a great strain on a computer or its network connections. Thus, you can use an old 486 or have a computer do double-duty as some other internal server. (It’s probably best to keep your network’s own NTP server inaccessible to the outside world for security reasons.) Be sure your NTP server has reliable access to the Internet at large.

The bulk of the work of configuring an NTP server is installing the software. Most major distributions ship with NTP software in a package called ntp, xntp, or something similar, so look for and install that package. You can also download the NTP software source code from http://www.ntp.org, but you’ll then need to compile and install the software yourself.

Once you’ve installed NTP, you configure it through the /etc/ntp.conf file. The most important configuration option in this file is the server line, which specifies an NTP server by hostname or IP address:

server 10.27.103.48
server time.example.org
server tempus.luna.edu

These three lines tell the NTP server to look to three other systems for its time: 10.27.103.48, time.example.org, and tempus.luna.edu. The order in which servers are listed is unimportant; the server determines which server has the most reliable time and uses it.

Change your ntp.conf file’s server lines so that they point to the NTP servers you identified earlier as being appropriate for you. List precisely one server per line; don’t try to combine multiple servers on a single line.

Although you need to change only the server lines, the /etc/ntp.conf file contains several other options that may be important. You should probably review the following:

*fudge is used to override the claimed stratum level of a server. It’s most often used in conjunction with the 127.127.1.0 address, which refers to a computer’s own local clock. For example, fudge 127.127.1.0 10 sets the computer’s own clock to stratum 10. The result is that NTP can use the local clock as a last-resort method of setting itself. (The stratum 10 value is somewhat arbitrary, but is intended to be much higher than any likely, true NTP server’s stratum.)

*The restrict keyword provides access control for an NTP server. Typically, the first such line is restrict default ignore, which tells NTP to ignore all incoming requests. You can then add lines like restrict 192.168.43.0 mask 255.255.255.0 to open the server to the specified range of IP addresses.

*For very security-conscious sites, NTP provides options such as keys, trustedkey, requestkey, and controlkey to provide authentication between clients and servers. These options require special configuration and are normally commented out or are simply not present in default ntp.conf files. (The use of authentication options is beyond the scope of this article.)

*The broadcast keyword tells NTP to regularly broadcast its time to an entire subnet, while the broadcastclient option tells NTP to listen for such broadcasts. Although these options can be a useful way of minimizing NTP traffic on large networks, they should be used with the authentication options, and so aren’t described here.

Once you’ve reviewed and adjusted your /etc/ntp.conf file, you should start the server. (If your computer’s time is off by more than a few minutes, you might want to set it to something that’s at least approximately correct first. NTP quits if your local time is greatly at odds with the time found on remote NTP servers.)

In most cases, you can start NTP with a SysV startup script, as in:

# /etc/init.d/ntpd start

Of course, if the server is already running, you should pass it the restart option rather than start. You can then check the server’s operation and configure your clients.

Testing the NTP Server

Once you’ve started the NTP software, you can begin monitoring its operation. This is best done with the ntpq program, which provides a number of commands for monitoring NTP’s operation. The most important of these is peers, which displays information on the NTP servers you’ve told NTP to use as time sources. Figure Two shows the peers command in action.