    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)