We take for granted that computers on a network have some means to set their clocks to the nominal time of day, even if those means amount to eyeball and wristwatch. How accurate can this be done in practice? Most folks who have to get to work on time set their wristwatch within a minute or two of radio or TV time and expect it to drift less than a minute over the month. This amounts to a rate error of about 23 parts per million (PPM), not bad for a temperature-stabilized wrist. Real computer clocks can be set by wristwatch usually within a minute or two, but some have rate errors 10 times that of a wristwatch. Nevertheless, in many applications the accuracy maintainable by a herd of wristwatch-wrangled network timekeepers might well be acceptable.
In a lackadaisical world where the only serious consequence of clock errors may be that electronic mail occasionally arrives before it is sent, it may not matter a lot if a clock is sometimes set backward or accumulates errors more than a minute per month. It is a completely different matter in a distributed airline reservation system in which a seat can be sold twice or not at all. In fact, there may be legal consequences when an online stock trade is completed before it is bid or the local station begins its newscast a minute before the network commercial. But, as Liskov [1] pointed out, there are a number of things you probably have not thought about for which synchronized clocks make many missions easier and some even possible.
Computer scientists like to model timekeeping in a distributed computer network as a happens-before relation; that is, every event that occurs in one computer must happen before news of that event gets to another computer. In our universe where the arrow of time is always increasing and nothing travels faster than light, if such a message contains the sending time, then the receiving time on arrival must always be later. In Lamport’s [2] scheme, all computer clocks are assumed to run at the same rate. Every message contains the time it was sent according to the sender’s clock. If that time is later than the receiver clock, the receiver clock is advanced to that time. The hap-pens-before relation would always be satisfied, even if the station stops were wrong according to the train schedule.
In Lamport’s [2] scheme, time is never set backward, which would surely violate the happens-before relation. However, real network clocks can run at significantly different rates, and it takes a while for news of an earthquake in California to arrive in New York. So, an electronic timekeeping protocol needs some wiggle room to adjust the rate of each clock to maintain nominal time agreement with the national timescale. To do this, a distributed network clock synchronization protocol is required that can read a server clock, transmit the reading to one or more clients, and adjust each client clock as required. Protocols that do this include the topic of this topic, the Network Time Protocol (NTP) [3], as well as the Digital Time Synchronization Service (DTSS) [4] protocol and others found in the literature.
Simply stated, NTP is a distributed service that synchronizes the computer clock to an ensemble of sources, either remote via the Internet or local via a radio, satellite, or telephone modem service. We speak of the server clock, which offers synchronization, and one or more client clocks that accept it. When the meaning is clear from context, we refer to the local clock in some client or server as the system clock. NTP aligns the system clocks in participating computers to Coordinated Universal Time (UTC)* used by most nations of the world. UTC is based on the solar day, which depends on the rotation of Earth about its axis, and the Gregorian calendar, which is based on revolution of Earth around the Sun. The UTC timescale is disciplined with respect to International Atomic Time (TAI) by inserting leap seconds at intervals of about two years. UTC time is disseminated by various means, including radio, satellite, telephone modem, or portable atomic clock.
In spite of the name, NTP is more than a protocol; it is an integrated technology that provides for systematic dissemination of national standard time throughout the Internet and affiliated private and corporate networks. The technology is pervasive, ubiquitous, and free of proprietary interest. The ultimate goal of NTP is to synchronize the clocks in all participating computers to the order of less than a millisecond or two relative to UTC. In general, this can be achieved with modern computers and network technologies. This is easily good enough to detect things like stalled central processing unit (CPU) fans and broken heating or cooling systems by calibrating the measured frequency offset to the ambient temperature.As demonstrated in that topic, the ultimate accuracy at the application program interface (API) of a modern computer with access to a precision timing source is on the order less than a microsecond.
Synchronization directly to UTC requires a specialized radio or satellite receiver or telephone modem service. Such sources, called reference clocks in this topic, are available for many government dissemination services, including the Global Positioning System (GPS) and Long Range Navigation System (LORAN-C) radio navigation systems, WWV/H and WWVB radio time/frequency stations, U.S. Naval Observatory (USNO), and National Institute of Standards and Technology (NIST; formerly National Bureau of Standards [NBS]) telephone modem services in the United States, as well as similar systems and services in other countries. If every computer were equipped with one of these clocks and rooftop space was available for their antennas, NTP would not be needed, and this topic could be recycled. But, a purpose-designed NTP server with a GPS antenna on one end and an Ethernet connection on the other cost $3,000 as this was written. Nonetheless, a clever electronic technician can hotwire a $100 Garmin GPS receiver to a serial port on a junkbox personal computer (PC) and do a decent job. The NTP software distribution even has drivers for it.
For reasons of cost and convenience, it is not possible to equip every computer with a reference clock. Furthermore, the reliability requirements for time synchronization may be so strict that a single clock cannot always be trusted. Therefore, even if a reference clock is available, most operators run NTP anyway with other redundant servers and diverse network paths. However, it is possible to equip some number of computers acting as primary time servers to wrangle a much larger herd of secondary servers and clients connected by a common network. In fact, USNO and NIST in the United States and their partners in other countries operate a fleet of Internet time servers providing time traceable to national standards. How this is done is the dominant topic of this topic.
