RFC685 日本語訳

Network Working Group                                Michael Beeler (BBN-TENEX)
Request for Comments: 685                                        April 16, 1975
NIC #32298

ネットワークワーキンググループマイケルBeeler(BBN-TENEX)はコメントのために以下を要求します。 685 1975年4月16日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.

交差しているネットワークデバッグはあるネットワーク・コンピュータのプログラマがaをデバッグできる手段がどれをプログラムするかということです。別のコンピュータでは、実行します。 1つの形式の十字ネットのデバッグは数年間ARPAネットワークでIMPsを維持するプログラマで使用中です。 別のフォームは遠方のコンピュータにログインして、そのマシンの上でデバッガを離れて走らせるのにTELNETかRSEXECを使うARPAネットワーク利用者によって使用されました。 これらのケースの両方では、デバッガは対象のプログラムと同じマシンでほぼ完全に居住しています、そして、そのコンピュータへのアクセスのリモート手段だけが単一のコンピュータデバッグと活動を区別します。

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.

場合では、私たちは、複雑なデバッグ操作を実行するのにPDP-10を使用します。 PDP-10が単純アクションに部分的に読みこなした簡単な操作、および複雑な動きをPDP-11へのARPAネットワークの上に送ります。 対象がプログラムを作るPDP-11のデバッガの居住者の一部、実行、単純アクションしか実行できない、(審査、預金、始め、停止、セット・ブレークポイントなど) 2台のマシンの間のデバッグ計算のこの分割は、BBNで実行されていて使用中です。 ユーザsマニュアルは、問題のいくつかが伴ったデバッガs機能と議論について説明しながら、利用可能です((BBN]<DOCUMENTATION>XNET.DOCとしての)。

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.

このRFCの目的はデバッガが示す応答時間の私たちの経験について説明することです。 応答時間はデバッガへのどんな労作の深刻な問題です。 ここで、ARPAネットワークの上で応答時間まで交信する貢献について議論したいと思います。 デバッガ(X-NET)は各デバッギング・セッションの間、統計を保ちます、そして、デバッガコマンドはそれらを印刷します。 私たちは、2回応答時間を測定するのに「標準のシナリオ」を使用しました。 1番目はPDP-10と同じIMPの上のBBNでPDP-11をデバッグしていました。 カリフォルニアのSRI-ARCのPDP-11、少なくとも9IMPsが介入している状態で、2番目がありました。

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

(地方)のBBNの様の(遠方)のTENEX負荷AVGスタート6.0 4.65終わり3.9 6.6時刻東部標準時15時30分の東部標準時11時0分の日の4/10/75の4/11/75の2ページ

Each session lasted about 10 minutes. The terms used below
are:

各セッションはおよそ10分続きました。 以下で使用された用語は以下の通りです。

message -- a single message generated by the PDP-10 portion of X-NET

メッセージ--X-NETのPDP-10部分で発生するただ一つのメッセージ

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.

バイト--すべての(8ビット)のバイトの合計、両方が、非同期な回答の領収書のためどんなバイト発信して、そのうえ、受信しました(例えば区切り点は当たりました)、関連メッセージか活発なコマンドの処理の間。

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

待ってください--X-NETでこれらのルーチンと劣った過程を通して実現言語(BCPL)ネットワークルーチン、回答の領収書にメッセージを手渡すのからの経過時間を合計してください。

The 35 active commands in the scenario are:

シナリオにおける35の活発なコマンドは以下の通りです。

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)

1 負荷プログラム8は、始まるか、または16が1が新しいコンテンツを預けるというメモリ単語のコンテンツを調べる1セットのメモリ単語区切り点1が取り外す1つの区切り点文字列検索1コピーがディスクファイル2ネットワーク/工程管理にプログラムするプログラム3停止プログラムを続かせます。(ユーザマニュアルを見ます)

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

1メッセージあたりの(地方)のBBNのSRI(遠方)のAVG STDデーウ・AVG STDデーウ: バイト154 295 164 295は活発なコマンドあたり1.75 2.04 1.89 0.78秒待っています: 1.60 2.36 1.73 1.35秒のMSGS0.91 0.69 0.91 0.69バイト150 331 150 331待ち

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

標準偏差は一部少ない数のサンプルにもかかわらず、メッセージサイズとコマンドの複雑さがさらに二つのモードであるのでさえ比較的大きいです、以下のヒストグラムで示されるように。 負荷と文字列検索命令は多くのバイトを移しました、したように審査、(最初のものはプログラムである間、止められました;、その後、審査、返答可能であった、キャッシュから; ユーザsが手動であることを見てください、) 他のコマンドはまずネットワーク取引を必要としませんでした。 全くなにも必要としなかった人が活発なコマンドあたりの待ち時間の分配における遅れがないモードを作成しました。 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.

私たちは、ネットワークコミュニケーションによる遅れが許容できると結論を下します。 それは適度にロードされたタイムシェアリングシステムでそんなにしばしば経験されるように大きさの同次のものです。一般に、進行中にはユーザ・プログラムで見られた遅れの、より明白な測定値がBBNにおいてほかの場所にあります。 それは、詳細にこれらの遅れについて議論するか、または過程起動、待ち行列、IMP性能などにそれらの原因を分解するためにこのRFCの範囲を超えています。 代わりに、私たちは、交差しているネットワークデバッグが実際には可能であることに単に注意します。

                 PER MESSAGE                 PER ACTIVE COMMAND
0                .                            XXXXXXXXX
16               .                            .
32               XXXXXXXXXXXXXXXXXXXXXXXXXX   XXXXXXXXXXXXXXXXXXX
64               .                            XXX
128              .                            .
256              XX                           .
512              XXXX                         XX
1024             .                            XX

活発なコマンド0XXXXXXXXX16.32XXXXXXXXXXXXXXXXXXXXXXXXXX XXXXXXXXXXXXXXXXXXX64XXX128.256XX. 512XXXX XX1024XXあたりのメッセージ単位で

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.

左のコラムのSIZE(BYTES)、BBN(ローカルのデータ)=SRI(遠方のデータ)は対数目盛で(包括的)であるのに下界を与えます。 したがって、2つのメッセージには、少なくとも256バイトにもかかわらず、512バイト未満がありました。 活発なコマンドあたりのネットワークトラフィックの試験は、それが実際にtrimodalであることを示します: ネットワークトラフィックを全く被らないで、いくつかのコマンドがキャッシュから答えられます。 始めか停止などのいくつかがほんのいくつかを何十バイトも必要とします。 そして、文字列検索や負荷などのいくつかのコマンドが何千バイトもの転送を引き起こします。

                 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

活発なコマンド0XXXXXXXXX1/16X.1/8.1/4X.1/2XXXXXXXXXX XXXXXXXX1XXXXXXXXXXXXXX XXXXXXXXXXX2XXXX XXXX4X X8X XXあたりのメッセージ単位で

WAITING TIME (SEC), BBN (local data)

                                                                      Page 4

WAITING TIME(SEC)、BBN(ローカルのデータ)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                .                            .

活発なコマンド0XXXXXXXXX1/16 . . 1/8.1/4X.1/2XXXXXX XXX1XXXXXXXXXXXX XXXXXXXXX2XXXXXXXXXXXXX XXXXXXXXXXXX4XX8あたりのメッセージ単位で。

WAITING TIME (SEC), SRI (distant data)

待ち時間(SEC)、様(遠方のデータ)