RFC618 日本語訳

Network Working Group                                   Edward Taft (PARC-MAXC)
Request for Comments: 618                                             Feb 1974
NIC #21989

ネットワークワーキンググループエドワードタフト(PARC-MAXC)はコメントのために以下を要求します。 618 1974年2月のNIC#21989

                A Few Observations on NCP Statistics

NCP統計におけるいくつかの観測

The NCP in use at HARV-10, CMU-10A, and CMU-10B collects a number of
operating and error statistics, which may be typed out on demand by
any user by means of the 'IMP ERROR' command, as shown on the sample
typescript.

HARV-10、米カーネギーメロン大学-10A、および米カーネギーメロン大学-10Bで使用中のNCPは多くの作動と誤り統計を集めます、サンプルタイプ版に示されるように。(統計は'IMP ERROR'コマンドによってどんなユーザによっても要求に応じてタイプで打たれるかもしれません)。

    The figures shown cover the period since the system was last
    restarted. They are not logged or recorded in any more permanent
    form due to extremely limited on-line storage at HARV-10. where
    the software was implemented. However, due to the small size of
    the system and infrequent monitor development work, HARV-10 tends
    to stay up for periods approaching the interval between hardware
    maintenance, which is one week. The attached output was obtained
    after 168 hours system uptime.

カバーがシステムが最後である時から期間に見せられた数字は再開しました。 それらが登録されないか、またはもっと多くのものに記録されて、ソフトウェアが実行されたところに永久的なフォームはHARV-10での非常に限られたオンライン格納を登録されます。 しかしながら、システムと珍しいモニター開発事業の小型のため、HARV-10は、期間、ハードウェアの保守管理の間隔にアプローチしながら寝ずに起きている傾向があります。ハードウェアの保守管理は1週間です。 168時間のシステム・アップタイムの後に付属出力を入手しました。

There are a few things I would like to point out that may be of
interest to NCP implementers.

指摘したいと思うNCP implementersに興味があるかもしれないいくつかのことがあります。

First, note that the number of discarded (unexpected) RFNMs is equal
to the number of simulated (timed out) RFNMs. This has been the case
almost every time I have looked at these statistics. It suggests
that the RFNMs are not being lost but are rather delayed beyond the
NCP timeout interval, which I believe is 30 seconds.

まず最初に、捨てられた(予期していなかった)RFNMsの数がシミュレートされた(外では、調節されている)RFNMsの数と等しいことに注意してください。これは私がこれらの統計を見たほとんど毎時のそうです。 それは、RFNMsが失われていませんが、NCPタイムアウト間隔にむしろ遅れるのを示します。(私は30秒であると間隔を信じています)。

    I have heard talk among a few people in the Network community
    about "lost RFNMs", and would like to suggest this as a possible
    alternative explanation. Perhaps longer timeouts are in order.

Network共同体の数人の人々で「無くなっているRFNMs」に関して話を聞いて、可能な代替の説明としてこれを勧めたいと思います。 恐らく、より長いタイムアウトは整然としています。

Second, the observed ratio of received allocates to transmitted
allocates (on the order of two to one) is also fairly typical. I
believe this reflects differences in allocation strategies among
various hosts.

2番目、観察比、受け取られている、伝えられることへの割り当て、割り当て、また、かなり典型的です(2〜1の注文に関して)。 私は、これが様々なホストの中で配分戦略の違いを反映すると信じています。

    Many hosts appear to send out an allocate for every data message
    received. While this is reasonable for connections such as FTP
    data transfer connections, it imposes considerable extra traffic
    in the case of the single character messages that seem to be the
    most common on the network.

多くのホストが、出すように見える、メッセージが受け取ったあらゆるデータのために、割り当てます。 FTPデータ転送コネクションなどの接続に、これは妥当ですが、それはネットワークで最も一般的であるように思えるただ一つのキャラクタメッセージの場合でかなりの余分な交通を課します。

                                  -1-


-1-

    The strategy used by the Harvard NCP is to assign a "desired level
    of allocation" figure to each socket (typically quite small for
    Telnet connections and large for FTP data connections; it is a
    user program settable parameter). When the actual allocation for
    the socket falls below 50% of this level, enough additional
    allocation is sent to bring it up to the full "desired level".

ハーバードNCPによって使用される戦略が「必要なレベルの配分」図を各ソケットに選任することである、(通常かなり小さい、FTPデータ接続に、接続であって大きいTelnetのために; それがユーザ・プログラム「舗装用敷石-可能」パラメタである、) ソケットのための実際の配分が下がるとき、それを完全な「必要なレベル」まで持って来るためにこの平らで、十分な追加配分の50%未満を送ります。

    The effect of this strategy is to significantly reduce the number
    of allocates returned for a given number of small messages
    received. This reduces both network traffic and control message
    overhead at the other end. The strategy has no effect on FTP data
    messages, since each message is usually large enough to reduce
    outstanding allocation by at least half at a single blow.

この戦略の効果がかなり数を減らすことになっている、受け取られた小さいメッセージの与えられた数のために返して、割り当てます。 これはもう一方の端のときにネットワークトラフィックとコントロールメッセージオーバーヘッドの両方を下げます。 戦略はFTPデータメッセージで効き目がありません、それぞれのメッセージが通常一撃の下に傑出している配分を少なくとも半分抑えることができるくらい大きいので。

Finally, I should remark on the appallingly large number of NOPs
received (typically 25% of all control messages). Most of these seem
to be piggy-backed onto other control messages, so the situation is
not as awful as the figures would indicate. Nevertheless, I am
forced to wonder why anyone would want to send so many.

最終的に、私は受け取られた多くのNOPs(通常すべてのコントロールメッセージの25%)について言うべきです。 これらの大部分が他のコントロールメッセージに背負われるように思えるので、状況は数字が示すだろうというほどひどくはありません。 それにもかかわらず、私は、だれかなぜそれほど多くを送りたがっているかとやむを得ず思います。

TELNET typescript file started at THU 31 JAN 74 428:05

TELNETのタイプで打っているファイルは31 1月の74日木曜日に428を始めました:、05

#harv-10 (settings loaded) is complete.#

#harv-10(設定はロードされた)は. #、を完成することです。

Harvard 5.06A-18 7:28:38
Type "HELP" if you need it.

ハーバード5.06A-18 7: あなたがそれを必要とするなら、28:38Typeは「助けます」。

.login 62,#
JOB 2 Harvard 5.06A-18 TTY25
Your name please (last name first): Taft
You are logged in as 62,404000
0728 31-Jan-74 Thur
SCHEDULED PM ON THURSDAYS, 0830-1200 EOT

.login62、JOB2ハーバード5.06A-18 TTY25 Yourが命名する#、は喜ばせます(最後に1番目を命名してください): タフト、あなたは62、404000 0728 31-Jan-74トゥールSCHEDULED PM ON THURSDAYS、0830-1200EOTとしてログインされます。

.imp error

.imp誤り

NCP version 1573.1604 operating statistics

NCPバージョン1573.1604 操作統計

07:29:02 31-JAN-74

07:29: 02 31 1月の74

NCP (link 0) message errors:
Socket not found: 2184

NCP(リンク0)メッセージ誤り: ソケットは当たりませんでした: 2184

                                  -2-


-2-

Improper state: 323
Illegal message type: 2
Last discarded allocation from PARC-MAXC (XEROX) link 12
Timed-out exec ICPs: 3

不適当な州: 323 不法なメッセージタイプ: 2は最後にPARC-MAXC(ゼロックス)リンク12外のTimed幹部ICPsから配分を捨てました: 3

NCP messages:
Type Received Sent
NOP 81850 0
RTS 3688 2507
STR 2388 3562
CLS 6055 6059
ALL 183050 101442
GVB 772 0
RET 0 772
INS 109 0
ECO 7472 15426
ERP 15065 7472
ERR 2 0
RST 2782 226
RRP 162 2782

NCPメッセージ: 受け取られたタイプがNOP81850 0RTS3688 2507STR2388 3562CLS6055 6059にすべての183050 101442GVBを送った、772、0、浸水、0 772INS109 0ECO7472 15426ERP15065 7472が間違える、2 0RST2782 226小売希望価格162 2782

Received NCP error messages:
Type Count
4 2

受信されたNCPエラーメッセージ: カウント4 2をタイプしてください。

Most recent error: type 4 from UCLA-CCN
Data (octal) 4 74 0 10 0 0 74 254 0 200
(decimal)    4 60 0  8 0 0 60 172 0 128

最新の誤り: UCLA-CCN Data(8進)4 74 0 10 0 0 74 254 0 200(10進)4 60から4をタイプしてください、0 8 0 0、60、172、0、128

IMP data message faults:
Hardware fault: 2
Link not found: 8
Discarded RFNMs: 10
Simulated (timed out) RFNMs: 10

IMPデータメッセージ欠点: ハードウェアの故障: 2リンクは当たりませんでした: 8 捨てられたRFNMs: 10はRFNMsをシミュレートしました(外では、調節されています): 10

Received IMP messages:
Regular 590812
Err w/o id 3
NOP 4
RFNM 490095
Dest dead 366
Inc trans 52
IMP reset 2

受信されたIMPメッセージ: イド3NOP4RFNM490095のDestの死んでいる366Inc移-52IMPのない通常の590812Errは2をリセットしました。

Histogram of received data message sizes
Bits Count
<1 3
<16 146834
<32 39751

受信データメッセージのヒストグラムはBits Count<1 3<16 146834<32 39751を大きさで分けます。

                                     -3-


-3-

<64 7044
<128 196983
<256 46099
<512 147609
<1024 534
<2048 1820
<4096 1152
<8192 2979

<64 7044<128 196983<256 46099<512 147609<1024 534<2048 1820<4096 1152<8192 2979

72 free buffers
7% average buffer utilization

72 7%が平均する無料のバッファは利用をバッファリングします。

.kjob/k
Job 2, User [62,404000] Logged off TTY25 0729 31-Jan-74
Runtime 0 Min, 03.29 Sec

.kjob/k仕事2、分、03.29秒のTTY25 0729ランタイム0 1974年1月31日から登録されたユーザ[62、404000]

                                  -4-

-4-