Request for Comments: 685
April 16, 1975
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.
Each session lasted about 10 minutes. The terms used below
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
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
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 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 . .