RFC 685

Okay bestie, let's get into this RFC! 🦋

Quick title-block tea first: this is RFC 685, written by Michael Beeler of BBN-TENEX and dated April 16, 1975 📅. It's also tagged NIC #32298 🎀. The original doesn't list a category or say what it obsoletes or updates, so I'm not making that up 🙈.

---

The Vibe Check 🌸

Okay so, cross-network debugging is when a programmer at one computer debugs a program running on a different computer, and it's giving main character energy 💅. There are two versions people have been using for a while. The first is for folks who maintain IMPs on the ARPA network. The second is for ARPA network users who use TELNET or RSEXEC to log into a far-away computer and run a debugger there remotely. In both cases the debugger lives almost entirely on the same machine as the program, and the only thing that makes it "remote" is how you get in 🧚.

Here's the spicy part 🔥. The BBN crew uses a PDP-10 for the complicated debugging stuff. Simple moves, plus complex stuff the PDP-10 has already chopped into simple steps, get sent over the ARPA network to a PDP-11. The debugger piece on the PDP-11, where the program is actually running, can only do simple things like examine, deposit, start, stop, and set breakpoint 💖. This split is already built and in use at BBN. There's a user's manual, (BBN]<DOCUMENTATION>XNET.DOC, that explains the features and some of the issues 📖.

Why We're Here 🦋

The goal of this RFC is to share what they learned about response times in this debugger. Slow response is a big deal for any debugger upgrade, so this RFC looks at how talking over the ARPA network adds to that delay 😭. The debugger, called X-NET, keeps stats during each session, and there's a debugger command that prints them out 🧮.

They ran a "standard scenario" twice to measure things. The first run was debugging a PDP-11 at BBN on the same IMP as the PDP-10 🏠. The second was a PDP-11 at SRI-ARC in California, with at least nine IMPs in between 🌈. Here's the setup:

                BBN (local)      SRI (distant)
TENEX LOAD AVG      6.0              4.65
START
FINISH              3.9              6.6
TIME OF DAY     15:30 EST        11:00 EST
DAY             4/10/75          4/11/75

Wait, I need to keep the table exact, so here it is verbatim 👇:

                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

Each session lasted about 10 minutes ⏰. Here are the terms they use, bestie:

• message: a single message the PDP-10 part of X-NET makes 💌.
• active command: a command that involves, really or virtually, talking to the program being debugged. Think examine, deposit, start, stop, set breakpoint, and so on ✨.
• bytes: all the 8-bit bytes sent and received, plus any bytes from asynchronous replies (like a breakpoint hit), while handling a message or active command 🫶.
• wait: total elapsed time from handing a message to the BCPL network routines, until the reply comes back from those routines and through an inferior process in X-NET ⏳.

The Scenario Breakdown 🎀

The scenario has 35 active commands, and they're giving a whole lineup 💅:

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)

And here are the summary stats, no cap 🧁:

                              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 kinda big, and that's partly because they only had a few samples 🙈. The real reason is that message size and command complexity are bimodal, which the histograms below show. The load and word search commands moved lots of bytes, and so did an examine. The first examine happened while the program was halted, and later examines got answered from the cache (check the user's manual). Other commands barely touched the network, and the ones that touched it not at all made a no-delay mode in the waiting-time distribution per active command 🌙.

Okay here's where it gets extra 🤯. Looking at network traffic per active command, it's actually trimodal. Some commands get answered from the cache and cause zero network traffic 🙅. Some, like start or stop, only need a few tens of bytes 🌷. Some, like word search and load, transfer thousands of bytes 💥.

Here's the histogram for the size in bytes. The BBN (local) data and the SRI (distant) data both use the same chart, and the left column is the lower bound (inclusive) on a log scale. So two messages had at least 256 bytes but less than 512 bytes 🧠:

                 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.

Now the waiting-time histograms 🌸. These are the BBN (local) data first:

                 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)

And here's the SRI (distant) one 👀:

                 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)

The Verdict 👑

So what's the takeaway? They conclude the delay from network communication is tolerable 🫶. It's the same order of magnitude people often see on moderately loaded time-sharing systems 💜. There's more detailed measurement going on at BBN and elsewhere about delays user programs see in general, but this RFC doesn't go deep on it, and it doesn't break down causes like process activation, queueing, or IMP performance 🙈. What it does say is that cross-network debugging is possible in a practical sense ✨. Periodt 💅.

Slay, bestie. Cross-net debugging is real and it's not ratchet 🌈🎀