As per Relevance of the word computer, we have this rfc below:
Network Working Group Michael Beeler (BBN-TENEX
Request for Comments: 685 April 16, 1975
NIC #32298
Response Time in Cross-network
Cross-network debugging is a means whereby a programmer at
computer on a network can debug a program which executes on
computer. One form of cross-net debugging has been in use for
years by programmers who maintain IMPs on the ARPA network.
form has been used by ARPA network users who employ TELNET or
to log into a distant computer and remotely run a debugger on
machine. In both of these cases, the debugger is almost
resident in the same machine as the subject program, and only
remote means of access to that computer distinguishes the
from single-computer debugging
In our case, we use a PDP-10 to perform complex
manipulations. Simple manipulations, and complex actions which
PDP-10 has partially digested into simple actions, are sent over
ARPA network to a PDP-11. The portion of the debugger resident
the PDP-11, where the subject program executes, can perform
simple actions (examine, deposit, start, stop, set breakpoint
etc.). This division of debugging computation between the
machines is implemented and in use at BBN. A user s manual
available (as (BBN]<DOCUMENTATION>XNET.DOC) describing
debugger s features and discussing some of the issues involved
The purpose of this RFC is to describe our experience
response times the debugger exhibits. Response time is a
problem in any elaboration to a debugger. Here we wish to
the contribution of communicating over the ARPA network to
time. The debugger (X-NET) keeps statistics during each
session, and a debugger command prints them out. We used
"standard scenario" to measure response times on two occasions.
first was debugging a PDP-11 at BBN on the same IMP as the PDP-10.
The second was with a PDP-11 at SRI-ARC in California, with at
nine IMPs intervening
BBN (local) SRI (distant
TENEX LOAD
START 6.0 4.65
FINISH 3.9 6.6
TIME OF DAY 15:30 EST 11:00
DAY 4/10/75
4/11/75
Page 2
Each session lasted about 10 minutes. The terms used
are
message -- a single message generated by the PDP-10 portion of X-
active command -- a command which involves, actually or virtually
an interaction with the subject program (e.g., examine, deposit
start, stop, set breakpoint, etc.)
bytes -- the total of all (8-bit) bytes, both sent and received
plus any bytes due to receipt of asynchronous replies (e.g.,
breakpoint hit), during processing of the associated message
active command
wait -- total elapsed time from handing message to
language (BCPL) network routines, to receipt of the reply
these routines and through an inferior process in X-
The 35 active commands in the scenario are
1 load
8 start or proceed
3 halt
16 examine contents of memory
1 deposit new contents in memory
1 set
1 remove
1 word
1 copy program onto disk
2 network/process management (see user's manual
The summary statistics are:.
BBN (local) SRI (distant
AVG STD DEV AVG STD
PER MESSAGE
BYTES 154 295 164 295
WAIT 1.75 2.04 1.89 0.78
PER ACTIVE COMMAND
MSGS 0.91 0.69 0.91 0.69
BYTES 150 331 150 331
WAIT 1.60 2.36 1.73 1.35
The standard deviation is relatively large partly because of
small number of samples, but even more because the message size
the command complexity are bimodal, as shown by the
below. The load and word search commands transferred many bytes,
did an examine (the first one while the program was halted
subsequent examines were answerable from the cache; see user
manual). Other commands needed little or no network transaction
Those which needed none at all produced a no-delay mode in
distribution of waiting time per active command
Page 3
We conclude that the delay due to network communication
tolerable. It is of the same order of magnitude as that
experienced on moderately loaded time sharing systems.
explicit measurements of delays seen by user programs in general
in progress at BBN and elsewhere; it is beyond the scope of this
to discuss these delays in detail, or to break down their
into process activation, queueing, IMP performance, etc. Instead
we merely note that cross-network debugging is possible in
practical sense
PER MESSAGE PER ACTIVE
0 .
16 . .
32 XXXXXXXXXXXXXXXXXXXXXXXXXX
64 .
128 . .
256 XX .
512 XXXX
1024 .
SIZE (BYTES), BBN (local data) = SRI (distant data) Left
gives lower bound (inclusive) on logarithmic scale. Thus,
messages had at least 256 bytes but less than 512 bytes.
examination of network traffic per active command shows that it
actually trimodal: some commands are answered from the cache
incurring no network traffic; some, such as start or stop,
only a few tens of bytes; and some commands, such as word search
load, cause transfer of thousands of bytes
PER MESSAGE PER ACTIVE
0 .
1/16 X .
1/8 . .
1/4 X .
1/2 XXXXXXXXXX
1 XXXXXXXXXXXXXX
2 XXXX
4 X
8 X
WAITING TIME (SEC), BBN (local data
Page 4
PER MESSAGE PER ACTIVE
0 .
1/16 . .
1/8 . .
1/4 X .
1/2 XXXXXX
1 XXXXXXXXXXXX
2 XXXXXXXXXXXXX
4 .
8 . .
WAITING TIME (SEC), SRI (distant data
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
