Some Thoughts on SRI's Proposed Real Time Clock
Thoughts on using host clocks to measure network message delays.
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 ]
ISO Plain Language
On this page
§1Measure Delays Inside Hosts
The note says existing network measurement facilities do not include internal host delays, which may be an appreciable part of the delay for a host-to-host message. Adding a clock to one or more network hosts could support user-oriented delay measurements.
Extending tracing to include internal host delays would require a clock at both the source and destination, but those clocks would not need to be especially accurate or synchronized. Measuring absolute overall delay from one host to another would require synchronized clocks.
Messages can spend time being handled inside each host, not just traveling between hosts. Measuring the full delay between two hosts requires their clocks to be synchronized.
§1Suggested Clock Characteristics
The author suggests that the SRI real-time clock have a resolution of about 1 msec, accuracy of about 1 part in 10E7, and a range of about 24 hours. The note says a crystal-controlled clock should meet these requirements at moderate cost.
It also raises the question of how the host reads the clock. A 1 msec resolution may require a hardware clock rather than a core-memory location incremented at each clock pulse, which could require complicated interface circuitry.
The proposal gives targets for clock resolution, accuracy and range. It also points out that the computer needs a way to read the clock quickly enough.
§1UCLA's Existing Clocks
The note says UCLA had two clocks on its Sigma 7, including one with a resolution of about 2 msec. That clock might be useful for some internal host measurements.
However, the note says it did not have the long-term accuracy needed for absolute measurements between hosts.
A UCLA clock could measure some delays inside a host. The note says it was not accurate enough over the long term for absolute measurements between hosts.