Summary

  • NIST's first Internet time server checked its own clock by calling the ACTS telephone service; the early experiment used a call every 3,000 seconds.
  • The later operating record shows why answering requests and maintaining correct time required separate attention, from modem failures to client software that mistook silence for the year 2037.

A timekeeper with a telephone bill

The machine telling other computers the time had to make a phone call to find out how it was doing. There is something pleasingly domestic about that arrangement. The Internet's clock could serve the network, provided it remembered to ring home.

In a paper for the 1993 PTTI meeting, Judah Levine described the new NIST Internet Time Service. Its first server was in Boulder, Colorado. It answered requests in Daytime, Time and NTP formats, giving different kinds of computer a way to obtain UTC(NIST), the time scale maintained by National Institute of Standards and Technology.

The paper's account of server synchronisation supplies the delightful plumbing. Initially, the server called the Automated Computer Time Service, or ACTS, once every 3,000 seconds. Those calls kept its clock within about 0.8 milliseconds RMS of UTC(NIST) in the reported experiment. Network travel then added its own uncertainty on the way to the user.

The telephone had changed jobs. Levine's example Internet client could obtain time without making a toll call itself. The reference check took place upstream, where one maintained clock could answer other machines.

Two connections, two chores

NIST's May 2002 operating report, describing the service as of November 2001, makes the arrangement explicit. Each time server had an analogue modem connected to a dedicated telephone line. It periodically dialled ACTS in Boulder. Incoming calls were ignored. Ethernet carried requests from the Internet.

The software also divided the work. One set of background processes supplied time codes; another steered the server's clock. Calibration calls typically came every few hours and lasted about 15 seconds. Between calls, the software used its model of the oscillator to keep making corrections. The short conversation bought a longer interval of useful timekeeping.

Some machines had extra help. Boulder servers received a direct one-pulse-per-second signal from the local reference. Some remote servers had rubidium equipment that improved short-term stability and provided limited holdover when a call could not be made. The service accommodated different physical arrangements around the same public interfaces.

Still answering, having a bad day

A telephone fault could leave a server quite capable of replying over the Internet while its clock lost contact with ACTS. NIST recorded both failed telephone lines and trouble at the ACTS service. A successful request therefore left another question for the client: what condition was the answering clock in?

During partial failures, the servers generally included bad-status information. Most client programs checked it and moved elsewhere. Some did not. The old Time format posed a sharper problem because it had no field for that status.

NIST tried silence. According to the report, many client programs interpreted no response as a time in 2037. Angry letters followed. An absent answer had become accidental time travel, with customer correspondence attached.

This small episode is the operating history in miniature. The engineer's sensible response to a sick clock ran straight into software already installed elsewhere. A service had to communicate failure in a form those machines could use.

The clock's less glamorous furniture

By November 2001, the report counted 14 operational servers, alongside test installations. NIST managed the service centrally; staff at remote host locations helped with hardware repairs. Manufacturer maintenance agreements supplied parts and labour. New software was tried on private servers before entering the public fleet.

There were also tapes in a fireproof safe: disk images, accompanied by notebooks recording hardware configurations and software revisions. These were useful companions to a precision clock. When a machine failed, somebody needed to know how to put its working state back together.

The public interface made obtaining time look easy. Behind it sat a telephone circuit, a clock model, a repair arrangement and a recoverable configuration. The Internet had acquired a convenient timekeeper. The timekeeper still had chores.