JANET Network Time Service
Technical Information
Introduction to Network Time Protocol (NTP)
Accurate time is needed across the network for a number of reasons, as well as being desirable on convenience grounds. Some security mechanisms rely on the time being the same in distributed systems; log scanning for security incidents is easier; information in mail headers and the like is more useful. Where file systems are updated by a number of computers (distributed systems), the computers' clocks need to be kept in step.
The JANET Network Time Service delivers a stable time reference to organisations using the Network Time Protocol (NTP) specified in RFC 1305. The RFC defines messages to be sent between systems, which contain the current time as known to the sender and other information sufficient for the NTP process running on each system to compensate for network delays and assess the quality of each source. By exchanging messages with a number of time sources the NTP server software can calculate a precise time with which it can synchronize the system's own local clock. The system can, in turn, be used to provide the time to others. This mesh of communicating systems gets "true time" from external references which may be atomic frequency standards, radio clocks that receive broadcast time signals from special dedicated transmitters, or the GPS (Global Positioning System) satellite navigation system. The result is that clock settings across the whole mesh are very closely synchronised and a single rogue system with the wrong time will have very little effect.
The number of steps a particular system is from an independent time source is called its "stratum". An external reference such as an atomic clock is stratum-0. A computer directly linked to an external clock and taking its time from it will be stratum-1. A computer obtaining time information from NTP sources including at least one stratum-1 will normally operate as stratum-2, and so on. Although having a low-stratum machine is broadly a good idea, it is not necessary in normal use and the majority of end-user systems will typically run at stratum-2, 3 or 4. An excessive number of clients on one server may adversely affect the system and thus the time quality. The Sun workstations used as JANET servers readily cope with 100 clients, but 1000 is too many. It is, therefore, a bad idea to try and run all machines at stratum-3.
NTP is designed to be resilient to failures and aberrant behaviour of clocks, servers and network links. Although at any one time a system will be using the time from only one server, it will typically be exchanging NTP messages with several other servers to provide redundancy and a quality check. For this to be effective, a site server should be configured to communicate with a number of servers that have independent paths to external sources of time, i.e. to different radio clocks. We recommend that a JANET site has up to four local servers (stratum-2) distributed around it, each server peering with a different JANET stratum-1 server. The local servers can in turn provide a feed for the rest of the site. This limits the NTP traffic across the wide-area network and the load on the stratum-1 servers.
NTP on Unix systems
The main NTP implementation is public-domain Unix software developed by the NTP author, David Mills of University of Delaware et al. The distribution is steadily being improved, and comes with a README file.
For Unix systems, the current production version is ntp-4.1.1 which implements the latest NTP 4 specification. Version 4 includes a number of enhancements over the NTP 3 specification. Version 3 software (xntp3-5.93) is still available.
Fetching and building the NTP software
For end-user Unix systems, xntpd itself is straightforward to build, install and configure on most platforms.
The xntpd distribution can be found at: http://www.ntp.org/
RFC1305 contains the full specification of the protocol as well as considerable background material on time.
The Makefiles for xntpd are sophisticated internally but simple to use, and can cope with the differences between most systems. In most cases, it should be sufficient to read the upper-level README files and just type " make " to build the software for the Unix platform. Then typing "make install", as root, will install it.
Having built and installed the xntpd daemon and various utilities, a configuration file will need to be created for the daemon to work properly. Notes on configuration of xntpd in general are in the "notes.html" file in the HTML subdirectory of the xntpd build. Some information, including quirks in particular systems that have caused people difficulty in the past, can be found in the "faq" file in the HTML subdirectory of the University of Delaware archive. The configuration files of the top-level servers for each site will need to be set to reference the JANET stratum-1 servers.
If you require any further help in fetching and building the software, then contact the JANET Operations Desk.
NTP on non-Unix systems
The University of Delaware distribution includes a "Simple NTP" client for MS Windows, and this is available as ntpsim.tar.Z. "Simple NTP" uses the standard NTP protocol to get the time from a server, but only sets the clock on the client machine - it does not contribute to the mesh of servers.
Your own clock
JANET organisations may wish to acquire their own stratum-0 radio or GPS clock and attach it to one of their servers, making it a stratum-1. This will improve the resilience of time distribution within the organisation, as the network distance to the JANET servers means reduced accuracy in comparison to an onsite clock. Radio clocks are available from various manufacturers and xntpd3 has support for most of those on the market.