doc: Add RFC documents

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)