From pogo, Walt Kelly
Pleased to meet you.
The Network Time Protocol (NTP) is used to synchronize the time of a computer client or server to another server or reference time source, such as a radio or satellite receiver or modem. It provides client accuracies typically within a millisecond on LANs and up to a few tens of milliseconds on WANs relative to a primary server synchronized to Coordinated Universal Time (UTC) via a Global Positioning Service (GPS) receiver, for example. Typical NTP configurations utilize multiple redundant servers and diverse network paths, in order to achieve high accuracy and reliability. Some configurations include cryptographic authentication to prevent accidental or malicious protocol attacks.
Background information on computer network time synchronization can be found on the Executive Summary - Computer Network Time Synchronization page. Discussion on protocol conformance issues and interoperability with previous NTP versions can be found in the Protocol Conformance Statement page. Discussion on year-2000 issues can be found in the Year 2000 Conformance Statement page. Background information, bibliography and briefing slides suitable for presentations can be found in the Network Time Synchronization Project page.
Bringing up a NTP primary server requires a radio or satellite receiver or modem. The distribution includes hardware drivers for over two dozen radio clocks and modem services. A list of the particular receivers and modem drivers supported in the distribution is given in the Reference Clock Drivers page. For most popular workstations marketed by Digital, Sun and Hewlett Packard, as well as widely available Unix clones such as FreeBSD and Linux, the automatic build procedures select all drivers that run on the target machine. While this increases the size of the executable binary somewhat, individual drivers can be included or excluded using the configure utility documented in the Configuration Options page.
NTP is by its very nature a complex distributed network application and can be configured and used for a great many widely divergent timekeeping scenarios. The documentation presented on these pages attempts to cover the entire suite of configuration, operation and maintenance facilities which this distribution supports. However, most applications will need only a few of these facilities. If this is the case, the Quick Start page may be useful to get a simple workstation on the air with an existing server.
However, in order to participate in the existing NTP synchronization subnet and obtain accurate, reliable time, it is usually necessary to construct an appropriate configuration file, commonly called ntp.conf, which establishes the servers and/or external receivers or modems to be used by this particular machine. Directions for constructing this file are in the Notes on Configuring NTP and Setting up a NTP Subnet page. However, in many common cases involving simple network topologies and workstations, the file data can be specified entirely on the command line.
The most important factor in providing accurate, reliable time is the selection of modes and servers to be used in the configuration file. NTP support for one or more computers is normally engineered as part of the existing NTP synchronization subnet. The existing NTP subnet consists of a multiply redundant hierarchy of servers and clients, with each level in the hierarchy identified by stratum number. Primary servers operate at stratum one and provide synchronization to secondary servers operating at stratum two and so on to higher strata. In this hierarchy, clients are simply servers that have no dependents.
The NTP subnet in early 1999 includes 79 public primary (stratum 1) servers synchronized directly to UTC by radio, satellite or modem and located in every continent of the globe except Antarctica (soon). Normally, client workstations and servers with a relatively small number of clients do not synchronize to primary servers. There are over 100 public secondary (stratum 2) servers synchronized to the primary servers and providing synchronization to a total in excess of 100,000 clients and servers in the Internet. The current lists are maintained in the Information on Time and Frequency Services page, which is updated frequently. There are numerous private primary and secondary servers not normally available to the public as well. You are strongly discouraged from using these servers, since they sometimes hide in little ghettos behind dinky links to the outside world and your traffic can bring up expensive ISDN lines, causing much grief and frustration.
In some cases where a network is isolated from the Internet and no external synchronization source is available, one of the network hosts can be designated as the primary server and the others operate as clients. In these cases the network hosts will be synchronized, but not necessarily to standard civil time. Even if an external synchronization source is available, a host can be designated as backup server in the event the external source becomes unreachable or inoperable. A host operating as the primary or backup server is configured with the Undisciplined Local Clock driver. The configuration options provide for a stratum number to be assigned to the server, usually one for a primary server and three or more for a backup server.
In the majority of cases, the NTP subnet can keep the clock within a few milliseconds on LANs and a few tens of milliseconds on WANs. However, in some cases with network jitter of several hundred milliseconds or more, the clock discipline loop may not be able to converge to a stable frequency. In such cases, a large fraction of the time sample corrections are greater than the 128-ms step threshold and valid updates which can discipline the clock frequency are sparse. In these cases, the burst keyword should be used with the corresponding server line in the configuration file. This causes eight volleys in each measurement round, following which the best candidate is determined and used to discipline the clock. See the Configuration Options page for further information.
When multiple servers are configured, the NTP algorithms operate to determine the best combination providing the highest accuracy. However, there may be small systematic differences in the apparent time of each server due to the different network paths involved. In practice, this can lead to occasional clockhopping between servers and result in increased jitter as seen by the clock discipline algorithm. Usually, a favored server can be selected so that, under most circumstances, only that server is used and the others disregarded. The favored server is identified by the prefer keyword in the corresponding server or peer line in the configuration file. See the Mitigation Rules and the prefer Keyword page for further information.
In general, as the poll interval increases, so does the expected error. When the highest accuracy is required, the poll interval should be clamped at a low value using the maxpoll keyword in the corresponding server or peer line in the configuration file. A typical argument value is 6, which results in a poll interval of 64 seconds. This should be done only sparingly, since it results in an increased load on the network. Where means are available, steps should be taken to minimize the ambient temperature variations, since the clock frequency is temperature dependent.
For the best accuracy, latencies in the hardware and software should by minimized wherever possible. Consider using the tty_clk line discipline, if available. Where available, interrupt-driven I/O is preferred over polled I/O. When means are available, the scheduling priority can be raised to avoid preempting the NTP daemon by other processes. This can be done using the -P option on the ntpd command line. However, this can lead to trouble should the daemon stumble on an endless program loop. While this is a "cannot happen" event, the possibility of this kind of bug should be considered in the overall robustness model for the client or server. See the ntpd - Network Time Protocol (NTP) daemon page for further information.
The very best accuracy can be achieved only by using an external discipline signal, such as a pulse-per-second (PPS) or Inter-Range Instrumentation Group (IRIG) signal. This requires external connection via a serial port or audio codec. See the Reference Clock Drivers page for further information and links to device drivers. Using the PPS signal and kernel support, for example, accuracies of a few microseconds can be achieved with modern workstation hardware.
Users are requested to report bugs, offer suggestions and contribute additions to this distribution. The Patching Procedures page suggests procedures which greatly simplify distribution updates, while the Porting Hints page suggest ways to make porting this code to new hardware and operating systems easier. Additional information on reference clock driver construction and debugging can be found in the Reference Clock Drivers page. Further information on NTP in the Internet can be found in the NTP web page.
David L. Mills <mills@udel.edu>