首页 > 学院 > 网络通信 > 正文

RFC685 - Response time in cross network debugging

2019-11-04 11:43:31
字体:
来源:转载
供稿:网友
Network Working Group                                Michael Beeler (BBN-TENEX)Request for Comments: 685                                        APRil 16, 1975NIC #32298            Response Time in Cross-network DebuggingCross-network debugging is a means whereby a programmer at onecomputer on a network can debug a program which executes on anothercomputer. One form of cross-net debugging has been in use for someyears by programmers who maintain IMPs on the ARPA network. Anotherform has been used by ARPA network users who employ TELNET or RSEXECto log into a distant computer and remotely run a debugger on thatmachine. In both of these cases, the debugger is almost entirelyresident in the same machine as the subject program, and only aremote means of access to that computer distinguishes the activityfrom single-computer debugging.In our case, we use a PDP-10 to perform complex debuggingmanipulations. Simple manipulations, and complex actions which thePDP-10 has partially digested into simple actions, are sent over theARPA network to a PDP-11. The portion of the debugger resident inthe PDP-11, where the subject program executes, can perform onlysimple actions (examine, deposit, start, stop, set breakpoint,etc.). This division of debugging computation between the twomachines is implemented and in use at BBN. A user s manual isavailable (as (BBN]<DOCUMENTATION>XNET.DOC) describing thedebugger s features and discussing some of the issues involved.The purpose of this RFCis to describe our eXPerience withresponse times the debugger exhibits. Response time is a seriousproblem in any elaboration to a debugger. Here we wish to discussthe contribution of communicating over the ARPA network to responsetime. The debugger (X-NET) keeps statistics during each debuggingsession, and a debugger command prints them out. We used a"standard scenario" to measure response times on two occasions. Thefirst 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 leastnine IMPs intervening.BBN (local) SRI (distant)TENEX LOAD AVGSTART 6.0 4.65FINISH 3.9 6.6TIME OF DAY 15:30 EST 11:00 ESTDAY 4/10/754/11/75                                                                       Page 2Each session lasted about 10 minutes. The terms used beloware:message -- a single message generated by the PDP-10 portion of X-NETactive 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 oractive command.wait -- total elapsed time from handing message to implementationlanguage (BCPL) network routines, to receipt of the reply fromthese routines and through an inferior process in X-NETThe 35 active commands in the scenario are:1 load program8 start or proceed program3 halt program16 examine contents of memory Word1 deposit new contents in memory word1 set breakpoint1 remove breakpoint1 word search1 copy program onto disk file2 network/process management (see user's manual)The summary statistics are:.BBN (local) SRI (distant)AVG STD DEV AVG STD DEVPER MESSAGE:BYTES 154 295 164 295WAIT 1.75 2.04 1.89 0.78 SECPER ACTIVE COMMAND:MSGS 0.91 0.69 0.91 0.69BYTES 150 331 150 331WAIT 1.60 2.36 1.73 1.35 SECThe standard deviation is relatively large partly because of asmall number of samples, but even more because the message size andthe command complexity are bimodal, as shown by the histogramsbelow. The load and word search commands transferred many bytes, asdid an examine (the first one while the program was halted;subsequent examines were answerable from the cache; see user smanual). Other commands needed little or no network transaction.Those which needed none at all prodUCed a no-delay mode in thedistribution of waiting time per active command. Page 3We conclude that the delay due to network communication istolerable. It is of the same order of magnitude as that oftenexperienced on moderately loaded time sharing systems. Moreexplicit measurements of delays seen by user programs in general arein progress at BBN and elsewhere; it is beyond the scope of this RFCto discuss these delays in detail, or to break down their causesinto process activation, queueing, IMP performance, etc. Instead,we merely note that cross-network debugging is possible in apractical sense. PER MESSAGE PER ACTIVE COMMAND0 . XXXXXXXXX16 . .32 XXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXX64 . XXX128 . .256 XX .512 XXXX XX1024 . XXSIZE (BYTES), BBN (local data) = SRI (distant data) Left columngives lower bound (inclusive) on logarithmic scale. Thus, twomessages had at least 256 bytes but less than 512 bytes. Anexamination of network traffic per active command shows that it isactually trimodal: some commands are answered from the cache,
incurring no network traffic; some, such as start or stop, requireonly a few tens of bytes; and some commands, such as word search andload, cause transfer of thousands of bytes. PER MESSAGE PER ACTIVE COMMAND0 . XXXXXXXXX1/16 X .1/8 . .1/4 X .1/2 XXXXXXXXXX XXXXXXXX1 XXXXXXXXXXXXXX XXXXXXXXXXX2 XXXX XXXX4 X X8 X XXWAITING TIME (SEC), BBN (local data) Page 4 PER MESSAGE PER ACTIVE COMMAND0 . XXXXXXXXX1/16 . .1/8 . .1/4 X .1/2 XXXXXX XXX1 XXXXXXXXXXXX XXXXXXXXX2 XXXXXXXXXXXXX XXXXXXXXXXXX4 . XX8 . .WAITING TIME (SEC), SRI (distant data)


发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表