Some Thoughts on SRI's Proposed Real Time Clock
Early proposal for adding a clock to network hosts for delay measurements
Cole, J., "Some Thoughts on SRI's Proposed Real Time Clock", RFC 32, DOI 10.17487/RFC0032, February 1970, <https://www.rfc-editor.org/info/rfc32>.
@misc{rfc32,
series = {Request for Comments},
number = 32,
howpublished = {RFC 32},
publisher = {RFC Editor},
doi = {10.17487/RFC0032},
url = {https://www.rfc-editor.org/info/rfc32},
author = {J. Cole},
title = {{Some Thoughts on SRI's Proposed Real Time Clock}},
pagetotal = 1,
year = 1970,
month = feb,
} RFC text
Network Working Group Jerry Cole, UCLA
Request for Comments: 32 February 5, 1970
SOME THOUGHTS ON SRI'S PROPOSED REAL TIME CLOCK
Re: NWG/RFC's #28 and 29.
The addition of a clock in one or more of the network HOST's seems to be
very desireable since it (or they) would allow user-oriented message
delay measurements. Our present network measurement facilities do not
include any internal HOST delays, and these delays may be an appreciable
portion of the total delay encountered by a HOST-to-HOST message
transmission. We may find that an extension of our "Trace" capabilities
to include internal HOST delays would be an appropriate mechanism for
utilizing such a clock. Such usage would require a clock at both the
source and the destination of the message, although such clocks would
not have to be particularly accurate nor synchronized. Other tests,
such as the absolute overall message delay from HOST A to HOST B would
require synchronization of the two clocks.
A reasonable specification for the SRI real-time clock would seem to
include a resolution of about 1 msec., an accuracy of about 1 part in
10E7 (so that two such clocks could maintain reasonable relative
accuracies over periods of many hours), and a range of about 24 hours.
A crystal controlled clock should easily meet these requirements at a
moderate cost.
The choice of the mechanism by which the HOST can read the clock appears
to be of concern also. The 1 msec. resolution may require that the
clock be entirely hardware (as opposed to a core location which would be
incremented at each clock pulse), and therefore the clock may require
some rather compli- cated interface circuitry.
At UCLA, we presently have two clocks on the Sigma 7, and one of these
has a resolution of about 2 msec. which might be usable for some
internal HOST measurements. However, it does not have the long term
accuracy for the absolute measurements mentioned above.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Richard Ames 1/98 ]
AI ELI5
On this page
§1The Need for Timing
Early network researchers needed to understand message delays, but their measurement tools only captured the time between hosts. They could not see delays that happened inside each computer while it was processing the message. The RFC proposes adding clocks to one or more network hosts to measure these internal delays.
To truly measure end-to-end delay from one host to another would require synchronized clocks at both ends, although relative delay measurements between two clocks would not require perfect accuracy.
Clocks let you measure how long something takes. If both ends have clocks, you can measure the whole journey, not just part of it.
§2Clock Specifications
The author proposes a clock system with three key properties. First, a resolution of about 1 millisecond to capture brief delays. Second, an accuracy of about 1 part in 10,000,000 so that two clocks would stay reasonably synchronized over many hours. Third, a range of about 24 hours of continuous measurement.
The proposal notes that a crystal-controlled clock could meet these requirements at moderate cost, though hardware considerations would be important: achieving 1 millisecond resolution might require entirely hardware-based implementation rather than a location in core memory that is incremented at each clock pulse.
A good clock needs to be fast enough to catch quick changes, accurate enough to stay right for hours, and remember a whole day's worth of time.
§3Practical Implementation
The author describes existing clocks at UCLA on their Sigma 7 computer. Two clocks were available, and one had a resolution of about 2 milliseconds, which might be usable for some internal host measurements. However, it lacked the long-term accuracy needed for absolute measurements between hosts.
The challenge was not just having a clock but providing an interface that let the host read it accurately. The note closes by inviting the working group to share opinions on the design before the protocol was finalized.
Building a clock is one thing; letting the computer read it fast enough is harder.