Unix Tip: NTP Commands

by Sandra Henry-Stocker

October 13, 2004 —

Send in your Unix questions today!

See additional Unix tips and tricks

Last week's column introduced NTP, the Network Time Protocol and the concept of highly accurate timekeeping. While numerous commands exist to help system administrators maintain fairly accurate time on the systems they manage, the most obvious are very limited. As a result, most networks suffer from large discrepancies in system time. Time differences such as those shown below (taken from an actual network) are not uncommon:

host01: Thu Oct 14 10:50:23 EDT 2004

host02: Thu Oct 14 10:43:53 EDT 2004

host03: Thu Oct 14 10:41:52 EDT 2004

host04: Thu Oct 14 10:50:13 EDT 2004

host05: Thu Oct 14 10:33:59 EDT 2004

host06: Thu Oct 14 14:48:17 GMT 2004

host07: Thu Oct 14 10:52:04 EDT 2004 *

host08: Thu Oct 14 10:52:33 EDT 2004

host09: Thu Oct 14 10:49:55 EDT 2004

host10: Thu Oct 14 10:33:20 EDT 2004 *

host11: Thu Oct 14 10:51:22 EDT 2004

Just within these eleven sequentially polled systems, we can see a considerable variability in the reported time. While the polls took place over the span of a few seconds, the time differences are considerably larger than a few seconds. There is, in fact, a difference of 18 minutes and 44 seconds between the earliest and latest reported times. Had we polled the entire network, the gap between the earliest and latest times reported would have been even wider.

To force systems such as these into more close time proximity, the systems administrator may use any of a number of commands with varying degrees of success.

The date Command

The date command which allows the sysadmin to set the date and time is the most obvious command for correcting the time on a system, but depends on the sysadmin having a fairly accurate time reference. This command is also run one system at a time. Using the date command to bring two systems into synch, a sysadmin is unlikely to get the system times closer than within a few seconds of each other. The date command is clearly not the command of choice when synchronization is important. And, on a network with several hundred systems, this approach can be both tedious and inaccurate.

Were a systems administrator to issue a date command in a loop such as the one shown below, the system times would be closer than those shown above, but would continue to vary by as many seconds as the loop took to complete. And, of course, this time variation will be increasingly significant if a password has to be entered for each ssh command.

for host in `cat host_list`
do
    ssh $host "date 10141045"
done

The date command is clearly only minimally useful in synchronizing systems. System clocks that tend to gain or lose time, even if only on the order of a couple of seconds each day, will quickly widen the time gaps again. In addition, systems configured for other time zones -- such as the one system reporting the time as GMT in the list shown above, would have their clocks thrown off by hours if we used the date command as shown.

The rdate Command

The rdate command, a far better choice for synchronizing clocks on a network, requires that a sysadmin select one system accessible to his/her network, presumably one that keeps fairly accurate time to use as a time reference for the rest.

The following loop would yield much better results than that shown above. After all, the time required for this loop to complete will have no detrimental effect since each rdate command will synch up to the time on the reference server when that command is run.

for host in `cat host_list`
do
    ssh $host "rdate timekeeper"
done

In addition, the rdate command does not override the time zone on the target system. Instead of setting the time literally to a value that is provided on the command line, rdate requests time data which is independent of the time zone. In other words, if you run "rdate " on a system using GMT, the time on the GMT system will be set correctly.

The rdate command is generally run at system start-up or through cron once a day or once an hour to align clocks on systems on a LAN. Compared to the undisciplined system clocks shown earlier, this is a great improvement. However, from the point of view of each system whose clock is reset with rdate, some very unusual things can happen. Clocks can jump forward or backward in time each time the rdate command is run. This behavior can lead to some very strange interpretations of time-sensitive events.

NTP Commands

NTP clearly has considerable advantages over the date and rdate commands. For one, NTP provides a way to synchronize system clocks with unusual precision and to make required adjustments smoothly, avoiding the jumps in time that commands such as rdate often cause. Let's take a closer look.

NTP provides two commands for time adjustment: the ntpdate command -- which sets the system time much as the rdate command does (i.e., by referencing a remote system to obtain the current time) and the NTP daemon -- ntpd or xntpd -- which provides a much more elaborate mechanism for arriving at and synchronizing to the proper time.

The ntpdate Command

The ntpdate command -- generally used, like the rdate command, at system startup, on demand or periodically through cron -- synchronizes time on a "ad hoc" basis in a similar manner to rdate. However, the ntpdate command has two very important advantages over rdate.

For one thing, ntpdate references an NTP server, not just a reliable timekeeper accessible to your network. Since NTP servers are generally tied into the NTP hierarchy (and, ultimately to a highly accurate atomic clock), they are almost guaranteed to be more precise than any server which simply has a good clock chip.

For another, ntpdate can collect a number of time samples from a number of time sources (i.e., multiple NTP servers) and then select the time which appears most accurate. So, not only does the ntpdate command reference a time source which is more likely to be accurate than those selected for use with rdate, but it references a number of such systems and applies a sophisticated selection process.

An ntpdate command might look like this:

# ntpdate 129.6.15.28
14 Oct 10:52:41 ntpdate[627]: adjust time server 129.6.15.28 offset -0.003350 sec

In fact, if the ntpdate command is installed on your system (/usr/sbin/ntpdate on most Solaris systems), you might try that exact ntpdate command right now. The reference server in this example is an NTP server at NIST in Gaithersburg, Maryland.

Alternately, you might try an ntpdate command like this:

# ntpdate 129.6.15.28 216.200.93.8 208.184.49.9
14 Oct 14:57:41 ntpdate[652]: adjust time server 216.200.93.8 offset 0.015733 sec

In this case, multiple NTP servers are queried.

The NTP Daemon

While the ntpdate command provides a level of time control that is an order of magnitude better than rdate, the NTP daemon goes a giant step beyond ntpdate with its sophisticated algorithms for maximizing accuracy and reliability. Used properly, the NTP daemon also uses a minimal amount of network resources -- we'll examine this issue next week.

The NTP daemon provides sophisticated algorithms that smoothly synchronize system clocks through a process of successive approximation. The longer the daemon runs, the more closely the system time matches that of its source. It makes large adjustments quickly and then smaller adjustments over time to avoid overshooting the proper time.

It may take NTP minutes or hours to approach a fine level of accuracy but, once it does, the time reliability on the system can be astoundingly accurate. That being said, the time accuracy of NTP is, however, ultimately tied to the accuracy of the time sources that it references. Each NTP server attempts to synchronize to UTC (i.e., Universal Coordinated Time) using the best time source and transmission path available. If the set of servers referenced transmit times which are not in close proximity to each other, NTP will consider one or more of these time servers to be broken and discount them. So, to get an accurate time using NTP, your choice of time servers must be accurate.

Newcomers to NTP should note that running the NTP daemon process does NOT necessarily make a system an NTP server. Whether an NTP-enabled system plays the role of client or server is determined by the daemon's configuration files on that system -- something we shall examine in next week's column.

ITworld.com