diff options
Diffstat (limited to 'doc/rfc/rfc685.txt')
| -rw-r--r-- | doc/rfc/rfc685.txt | 170 |
1 files changed, 170 insertions, 0 deletions
diff --git a/doc/rfc/rfc685.txt b/doc/rfc/rfc685.txt new file mode 100644 index 0000000..c11e727 --- /dev/null +++ b/doc/rfc/rfc685.txt @@ -0,0 +1,170 @@ +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) |