Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Response time in cross network debugging (RFC0685)

IP.com Disclosure Number: IPCOM000003733D
Original Publication Date: 1975-Apr-16
Included in the Prior Art Database: 2000-Sep-13
Document File: 3 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M. Beeler: AUTHOR

Abstract

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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 39% of the total text.

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]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,

p...