Response time in cross network debugging
How much delay does the ARPANET add to debugging?
Beeler, M., "Response time in cross network debugging", RFC 685, DOI 10.17487/RFC0685, April 1975, <https://www.rfc-editor.org/info/rfc685>.
@misc{rfc685,
series = {Request for Comments},
number = 685,
howpublished = {RFC 685},
publisher = {RFC Editor},
doi = {10.17487/RFC0685},
url = {https://www.rfc-editor.org/info/rfc685},
author = {M. Beeler},
title = {{Response time in cross network debugging}},
pagetotal = 3,
year = 1975,
month = apr,
} RFC text
Network Working Group Michael Beeler (BBN-TENEX)
Request for Comments: 685 April 16, 1975
NIC #32298
Response Time in Cross-network Debugging
Cross-network debugging is a means whereby a programmer at one
computer on a network can debug a program which executes on another
computer. One form of cross-net debugging has been in use for some
years by programmers who maintain IMPs on the ARPA network. Another
form has been used by ARPA network users who employ TELNET or RSEXEC
to log into a distant computer and remotely run a debugger on that
machine. In both of these cases, the debugger is almost entirely
resident in the same machine as the subject program, and only a
remote means of access to that computer distinguishes the activity
from single-computer debugging.
In our case, we use a PDP-10 to perform complex debugging
manipulations. Simple manipulations, and complex actions which the
PDP-10 has partially digested into simple actions, are sent over the
ARPA network to a PDP-11. The portion of the debugger resident in
the PDP-11, where the subject program executes, can perform only
simple actions (examine, deposit, start, stop, set breakpoint,
etc.). This division of debugging computation between the two
machines is implemented and in use at BBN. A user s manual is
available (as (BBN]<DOCUMENTATION>XNET.DOC) describing the
debugger s features and discussing some of the issues involved.
The purpose of this RFC is to describe our experience with
response times the debugger exhibits. Response time is a serious
problem in any elaboration to a debugger. Here we wish to discuss
the contribution of communicating over the ARPA network to response
time. The debugger (X-NET) keeps statistics during each debugging
session, and a debugger command prints them out. We used a
"standard scenario" to measure response times on two occasions. The
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 least
nine IMPs intervening.
BBN (local) SRI (distant)
TENEX LOAD AVG
START 6.0 4.65
FINISH 3.9 6.6
TIME OF DAY 15:30 EST 11:00 EST
DAY 4/10/75
4/11/75
Page 2
Each session lasted about 10 minutes. The terms used below
are:
message -- a single message generated by the PDP-10 portion of X-NET
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 or
active command.
wait -- total elapsed time from handing message to implementation
language (BCPL) network routines, to receipt of the reply from
these routines and through an inferior process in X-NET
The 35 active commands in the scenario are:
1 load program
8 start or proceed program
3 halt program
16 examine contents of memory word
1 deposit new contents in memory word
1 set breakpoint
1 remove breakpoint
1 word search
1 copy program onto disk file
2 network/process management (see user's manual)
The summary statistics are:.
BBN (local) SRI (distant)
AVG STD DEV AVG STD DEV
PER MESSAGE:
BYTES 154 295 164 295
WAIT 1.75 2.04 1.89 0.78 SEC
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 SEC
The standard deviation is relatively large partly because of a
small number of samples, but even more because the message size and
the command complexity are bimodal, as shown by the histograms
below. The load and word search commands transferred many bytes, as
did an examine (the first one while the program was halted;
subsequent examines were answerable from the cache; see user s
manual). Other commands needed little or no network transaction.
Those which needed none at all produced a no-delay mode in the
distribution of waiting time per active command.
Page 3
We conclude that the delay due to network communication is
tolerable. It is of the same order of magnitude as that often
experienced on moderately loaded time sharing systems. More
explicit measurements of delays seen by user programs in general are
in progress at BBN and elsewhere; it is beyond the scope of this RFC
to discuss these delays in detail, or to break down their causes
into process activation, queueing, IMP performance, etc. Instead,
we merely note that cross-network debugging is possible in a
practical sense.
PER MESSAGE PER ACTIVE COMMAND
0 . XXXXXXXXX
16 . .
32 XXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXX
64 . XXX
128 . .
256 XX .
512 XXXX XX
1024 . XX
SIZE (BYTES), BBN (local data) = SRI (distant data) Left column
gives lower bound (inclusive) on logarithmic scale. Thus, two
messages had at least 256 bytes but less than 512 bytes. An
examination of network traffic per active command shows that it is
actually trimodal: some commands are answered from the cache,
incurring no network traffic; some, such as start or stop, require
only a few tens of bytes; and some commands, such as word search and
load, cause transfer of thousands of bytes.
PER MESSAGE PER ACTIVE COMMAND
0 . XXXXXXXXX
1/16 X .
1/8 . .
1/4 X .
1/2 XXXXXXXXXX XXXXXXXX
1 XXXXXXXXXXXXXX XXXXXXXXXXX
2 XXXX XXXX
4 X X
8 X XX
WAITING TIME (SEC), BBN (local data)
Page 4
PER MESSAGE PER ACTIVE COMMAND
0 . XXXXXXXXX
1/16 . .
1/8 . .
1/4 X .
1/2 XXXXXX XXX
1 XXXXXXXXXXXX XXXXXXXXX
2 XXXXXXXXXXXXX XXXXXXXXXXXX
4 . XX
8 . .
WAITING TIME (SEC), SRI (distant data)
AI ELI5
On this page
§1Cross-Network Debugging
A programmer can debug a program running on a distant computer by sending commands over the ARPANET and waiting for replies. The debugger at BBN split the work: the local PDP-10 handles complex logic such as symbol resolution, while the remote PDP-11 in the subject program's machine handles simple actions like reading and writing memory, setting breakpoints, and starting or stopping execution.
The key question is whether network communication adds enough delay to make this work tedious. This note reports on measurements taken during actual debugging sessions, comparing a local debug session with one that crossed the country to SRI-ARC in California.
If you use a debugger on a computer across the country, is the wait unbearable? The team tested it to find out.
§2The Test Scenario
The test ran 35 debug commands in a standard sequence: loading a program, starting and stopping execution, examining and modifying memory, setting breakpoints, and other typical debugging tasks. Each session lasted about 10 minutes. Measurements were taken on two days with the same scenario: once debugging a PDP-11 on the same IMP as the PDP-10 at BBN, and once debugging a PDP-11 at SRI-ARC in California with at least nine IMPs in the path.
The collected statistics track the size of messages and the total elapsed wait time (from handing the command to the network routines until receiving the reply). The time includes all network round-trips and asynchronous replies such as breakpoint notifications.
The test used 35 real debugging commands. It measured how fast the computer answered when the debugger was next door versus when it was across the country.
§3Response Time Results
For local debugging at BBN, the average wait per message was 1.75 seconds with a standard deviation of 2.04 seconds. For the distant site at SRI-ARC, the average was 1.89 seconds with a lower standard deviation of 0.78 seconds. The difference due to network distance is about 0.14 seconds on average.
The distribution of message sizes was bimodal: some commands like loading and word search transferred thousands of bytes, while others like start and stop needed only a few tens of bytes. Cache effects also mattered: subsequent examines of the same memory location were answered locally without network traffic.
The standard deviation is high partly because the test had a small sample size, but more importantly because debugging workloads vary widely. Some commands incur no network traffic when answered from cache, while others cross the network.
The network added only about one-tenth of a second on average. The delays matched what you would see on a busy computer, not noticeably worse.
§4Practical Feasibility
The delays measured are tolerable. Network communication is of the same order of magnitude as delays that occur on moderately loaded time-sharing systems. The test did not break down delays into specific causes such as process activation, queueing, or IMP performance, but the overall result is clear: cross-network debugging is practical in use.
Network debugging works fine in the real world. The wait is not so long that people mind doing it.