Summary
- In 1985, network time was documented across three distinct records: RFC 958 described NTP messages, RFC 956 discussed clock-selection algorithms, and RFC 957 reported experiments.
- The experiment reported synchronization results under named links and conditions. Its few-millisecond findings required many samples; they were not a guarantee for every Internet clock.
A timestamp was not yet a shared clock
A time service can return a timestamp. That does not tell a client how trustworthy the clock is, whether the path delayed the message, or how to combine several observations. The first NTP documents make that distinction unusually visible.
RFC 958, published in September 1985, defined NTP’s data representation and message formats. Its packet carried more than a time value: it identified the reference clock and described the local clock’s precision, estimated error and drift. Four timestamps marked a request’s departure, arrival at the server, departure from the server and arrival back at the client. Those fields let a peer estimate offset and round-trip delay. The protocol did not, however, specify the algorithms that would choose among clocks or filter observations. It said that part remained for further study.
The separation mattered because real clocks disagreed for many reasons. Hardware, software, radio reception, network delay and operator error could all affect readings. RFC 956 treated synchronization as a statistical problem: compare observations, identify outliers and estimate which time is most credible. One reading was not a verdict about a clock.
The experiment used links that had other jobs
RFC 957 supplied the empirical counterpart. It described DCnet’s clock design and trials involving hosts, reference clocks and several kinds of link. Some tests examined clocks synchronized through paths that also carried ordinary data. The report was interested in the effect of sharing a network between timing and data traffic, not just in a quiet laboratory exchange.
A test series in late June and early July 1985 involved six hosts, three reference clocks and several communication links. Its timing was deliberate: the tests coincided with a leap second in the time broadcast by the National Bureau of Standards. The setup also examined whether power-line frequency could serve as a reference, though the report distinguishes observing that source from using it to adjust local clocks.
The report does not reduce those arrangements to one Internet-wide score. It records differences among hosts and links. Its conclusion is conditional: synchronization over ARPANET paths could reach the order of a few milliseconds when sufficiently large samples were available. RFC 956 likewise describes approximately ten-millisecond-order results for its tested data and emphasizes that many samples mattered. Those are findings about experiments, not a service-level promise.
Three documents, three kinds of evidence
The documents answer different questions. RFC 958 says what peers exchange. RFC 956 explains methods for interpreting noisy clock observations. RFC 957 reports how a particular implementation and test arrangement behaved. Conflating them would turn a proposed packet format into an algorithm, or an experiment into proof of universal operation.
RFC 1059, published in 1988, later described NTP as an architecture, protocol and set of synchronization algorithms—and said the design had evolved significantly since RFC 958. That later consolidation helps mark what the 1985 documents left open. It does not establish when every system adopted the later specification.
The historical achievement was therefore not a single perfect clock. It was an evidence chain: a message carried timing information; algorithms compared clocks and handled outliers; experiments measured results across real network paths. Whenever an old accuracy figure is repeated, its path, reference, sample count and operating conditions should travel with it. “A packet reported the time” is not the same claim as “the network synchronized its clocks.”
Sources
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
