RFC662 日本語訳

Network Working Group                                               Raj Kanodia
Request for Comments: 662                                      Project MAC, MIT
NIC #31386                                                            Nov. 1974

Kanodiaがコメントのために要求するワーキンググループ主権をネットワークでつないでください: 662 プロジェクトMAC、MIT NIC#31386 1974年11月

       PERFORMANCE IMPROVEMENT IN ARPANET FILE TRANSFERS FROM MULTICS

MULTICSからのアルパネットファイル転送における性能改良

With the growth of Multics usage in the ARPA Network community, users often 
need to transfer large amounts of data from Multics to other systems. However,
Multics performance in this area has been less than optimal and there clearly
exists a need to improve the situation. Even within Project MAC there are users
who regularly ship files back and forth between Multics and other Project MAC
computer systems. Recently the Cambridge Information Systems Laboratory (CISL)
development Multics system was connected to the ARPA Network. This has
generated considerable interest among the members of the CSR (Computer Systems
Research) and CISL groups in using the Multics file transfer facility for tran-
smission of Multics system tapes (MST) from one Multics system to the other.
At currently realizable data transfer rates, transmission of a typical MST,
(approximately 12 million bits), takes about half an hour. The usefulness of
the present file transfer system is severely limited by its low bandwidth.

Multics用法の成長がアーパネット共同体にある状態で、ユーザは、しばしばMulticsから他のシステムまで多量のデータを移す必要があります。しかしながら、この領域のMultics性能はあまり最適ではありません、そして、明確に、状況を改善する必要性は存在しています。 Project MACの中にさえ、Multicsの間で定期的にファイルを前後に出荷するユーザと他のProject MACコンピュータ・システムがあります。最近、ケンブリッジ情報システム研究所(CISL)開発Multicsシステムはアーパネットに接続されました。 これはCSR(コンピュータシステムズResearch)とCISLグループのメンバーの中でMulticsシステム・テープ(MST)のtran- smissionに1台のMulticsシステムからもう片方までMulticsファイル転送施設を使用する際に相当な興味を生みました。 現在実現可能なデータ転送速度では、典型的なMSTのトランスミッション(およそ1200万ビット)は30分頃に取ります。 現在のファイル転送システムの有用性は低い帯域幅によって厳しく制限されます。

One of the reasons for such a poor performance is the output buffering strategy
in the Multics IMP DIM (IMP Device Interface Manager.) With the hope of making
a significant performance improvement, we recently changed the IMP DIM buffer-
ing strategy. To assess the effects of this change an experiment was conducted
between the service machine (MIT Multics) and the development machine (CISL
Multics.) This memo reports the experiment and its results.

そのような不十分な性能の理由の1つはMultics IMP DIM(IMP Device Interfaceマネージャ)の戦略をバッファリングする出力です。 顕著な性能改良をするのにおいて、私たちが最近変化したという望みをもって、IMP DIMはing戦略をバッファリングします。 実験が行われたこの変化の効果を評価するために、サービスマシン(MIT Multics)と開発は(CISL Multics)を機械加工します。 このメモは実験とその結果を報告します。

PROBLEM

問題

Due to reasons that are of historical interest only, the output buffers in the
IMP DIM have been very small; each buffer can accommodate up to 940 bits only.
With the addition of a 72 bit long header, the resulting message has a maximum
length of 1012 bits, which in the Network terminology is a single packet
message. Due to this buffer size limit, Multics can transmit single packet
messages only, even though the network can accept up to 8096 bit long messages.
This results in increased overhead in the set up time for transmission of large
number of bits.

歴史的におもしろいだけである理由のために、IMP DIMの出力バッファは非常に小さいです。 各バッファは最大940ビットしか収容できません。 長さ72ビットのヘッダーの追加によって、結果として起こるメッセージには、最大1012ビットの長さがあります。(Network用語では、ビットはただ一つのパケットメッセージです)。 このバッファサイズ限界のため、Multicsはただ一つのパケットメッセージしか送ることができません、ネットワークが8096年の長さビットのメッセージまで受け入れることができますが。 これは多くのビットのトランスミッションのための時間へのセットで増強されたオーバーヘッドをもたらします。

An old version of the IMP-to-Host protocol requires that a host may not transmit
another message on a network connection unless a Request-for-Next-Message (RFNM)
has been received in response to the previous message. Even though this
restriction has now been relaxed, the protocol does not specify any way to
recover from transmission errors that occur while more than one RFNM is pending
on the same connection. If the constraint of transmitting only one message at a
time is observed there is at least some potential for recovery in case of an
error. 8eing reliability conscious, Multics observes the constraint imposed by
the old protocol. Following the old protocol introduces delays in the
transmission of successive messages on the same link and therefore the overall
bandwidth per connection is reduced.

IMPからホストへのプロトコルの古いバージョンは、次のメッセージのためのRequest(RFNM)が前のメッセージに対応して受け取られていない場合ホストが別のメッセージをネットワーク接続に送らないかもしれないのを必要とします。 この規制は現在緩和されましたが、プロトコルは1RFNMが同じ接続のときに未定である間に起こる伝送エラーから回復する少しの方法も指定しません。 一度に1つのメッセージだけを送る規制が観測されるなら、回復の少なくとも何らかの可能性が誤りの場合にあります。 8eingの信頼性の意識していて、Multicsは古いプロトコルによって課された規制を観測します。 古いプロトコルに従うと、同じリンクにおける連続したメッセージの伝達の遅れは導入されます、そして、したがって、1接続あたりの総合的な帯域幅は減少します。

                                      -1-

-1-

SOLUTION

ソリューション

At least one method of improving the file transfer bandwidth is obvious.
Increasing the size of IMP DIM output buffers will allow us to transmit
significantly larger messages<s1>s This will result in fewer RFNMs and delays and
improved bandwidth. We have made two assumptions here. The first assumption is
that the delay introduced by RFNMs does not increase with the size of the
message.<s2>s Our experience with the network tends to support this assumption.
The second assumption is that actual time taken to transmit a message increases,
at best, linearly with the size of message. This second assumption does not
hold for a heavily loaded network. But for our purpose we may assume it to be
essentially correct.

ファイル転送帯域幅を改良する少なくとも1つのメソッドが明白です。 かなり大きいメッセージ<s1>s Thisは、より少ないRFNMs、遅れ、および改良された帯域幅をもたらして、私たちがバッファで伝えることができるIMP DIM出力のサイズを増強するでしょう。 私たちはここで2を仮定にしました。 最初の仮定はメッセージのサイズに従ってRFNMsによって導入された遅れが増加しないということです。ネットワークの<s2>s Our経験は、この仮定をサポートする傾向があります。 2番目の仮定はメッセージのサイズに従って送信するにはかかる実際の時間が直線的をせいぜい増強するということです。 この2番目の仮定は大いにロードされたネットワークに当てはまりません。 しかし、目的のために、私たちは、それが本質的には正しいと思うかもしれません。

There is another advantage in transmitting large messages. For a given amount
of data, fewer messages will be transmitted, fewer RFNMs will be read, and
therefore time spent in the channel driver programs will be reduced. Since the
channel sits idle during at least some of this time, the idle time for the
channel will be reduced, resulting in improved channel bandwidth.

大きいメッセージを送るのにおいて別の利点があります。 与えられた量のデータに関しては、より少ないメッセージが送られて、より少ないRFNMsが読まれて、したがって、チャンネルドライバープログラムに費やされた時間は短縮されるでしょう。 チャンネルが少なくともこの時間のいくつかぽかんとしているので、チャンネルのための遊休時間は短縮されるでしょう、改良されたチャンネル帯域幅をもたらして。

EXPERIMENT

実験

We changed the IMP DIM to implement two kinds of output buffers. One kind of
output buffer is short and can hold single packet messages only. The other kind
of buffer is, naturally enough, large and can hold the largest message allowed
by the network. If the number of bits to be transmitted is low (this is mostly
the situation with interactive users,) a small buffer is chosen and if it is
large (for example, file transfers,) a large buffer is chosen.

私たちは、2種類の出力バッファを実装するためにIMP DIMを変えました。 1つのちょっと出力されたバッファが、短く、ただ一つのパケットメッセージだけを保持できます。 もう片方の種類に関するバッファは、十分自然に大きく、最も大きいメッセージがネットワークによって許容されているままにできます。 伝えられるべきビットの数が下位であるなら(これはほとんど対話的なユーザがいる状況です)、小さいバッファは選ばれています、そして、それが大きいなら(例えば、ファイル転送)、大きいバッファは選ばれています。

The new IMP DIM was used in an experimental Multics system on the development
machine at CISL. The service machine at MIT had the old version. Large files
were transmitted from the development system to the service system and the file
transfer rate was measured in bits per second ( of real time.) To get an
estimate of gain in the performance, files were transmitted from the service

新しいIMP DIMはCISLの開発マシンの上で実験用Multicsシステムで使用されました。 MITのサービスマシンには、古いバージョンがありました。 大きいファイルは開発システムからサービス・システムまで送られました、そして、ファイル転送率はbps(リアルタイムでの)で測定されました。 性能における、利得の見積りを得るために、ファイルはサービスから送られました。

<s1>s In one situation it may not be possible to transmit large messages. The
number of messages and bits that a host can transmit on a particular connection
must not exceed the message and bit allocation provided by the receiving host.
If a receiving host gives very small bit allocation, then the sending host can
not transmit very large messages. Since Multics always gives out very large
allocations, there should be no problem in Multics to Multics file transfers.

それが可能でないかもしれない1つの状況における<s1>sは大きいメッセージを送ります。 ホストが特定の接続に送ることができるメッセージとビットの数は配分が受信ホストで提供したメッセージとビットを超えてはいけません。 受信ホストが非常に小さい噛み付いている配分を与えるなら、送付ホストは非常に大きいメッセージを送ることができません。 Multicsがいつも非常に大きい配分を配るので、問題が全くMulticsファイル転送へのMulticsにあるべきではありません。

<s2>s It should be noted that the size of RFNM is fixed and does not change 
with the size of message.

<s2>s、RFNMのサイズが固定されていて、メッセージのサイズを交換しないことに注意されるべきです。

                                      -2-
system to the development system and the old file transfer rate was measured.
The same file, approximately 2.5 million bits long, was used in both
experiments. The BYTE-SIZE and MODE parameters of the ARPANET File Transfer
protocol were set to 36 and "image" mode respectively. This implies that no
character conversion was performed in the file transfer. The following table
shows the results obtained:

-2 -開発システムと食えない奴転送レートへのシステムは測定されました。 同じ長さおよそ250万ビットであるファイルは両方の実験に使用されました。 アルパネットFile TransferプロトコルのBYTE-SIZEとMODEパラメタはそれぞれ36と「イメージ」モードに用意ができていました。 これは、キャラクタ変換が全くファイル転送で実行されなかったのを含意します。 以下は結果が得たショーを見送ります:

Service to Development Development to Service
(old system) (new system)

Service(古いシステム)へのDevelopment Developmentに対するサービス(新しいシステム)

average file-
transfer rate 6,837 27,578
(bits per second)

平均したファイル転送レート6,837 27,578(bps)

The following information regarding the environment of the experiment is
supplied for the sake of completeness. At the time of this experiment, the
service system was lightly loaded (the system load varied between 30.0 and
35.0). The service system configuration was 2 cpu's and 384 K primary memory.
The development machine configuration was 1 cpu and 256 K of primary memory.
The development system load was limited to the file transfer processes and the
initializer process. The MIT Multics is connected to the IMP number 44 (port 0)
by a rather short cable (approximately 100 feet long.) The CISL Multics is
connected to the IMP number 6 (port 0) by an approximately l5OO feet long cable.
8oth IMPs are in close physical proximity (approximately 2000 feet,) and are
connected to each other by a 5O kilobits per second line. The results given
above show considerable improvement in the performance with the new IMP DIM.

完全を期すために実験の環境の以下の情報を提供します。 この実験時点で、サービス・システムは軽くロードされました(システム・ロードは30.0〜35.0を変えました)。 サービスシステム構成は、2cpuのものと384Kの主記憶装置でした。 開発機械コンフィギュレーションは1cpuと256Kの主記憶装置でした。 開発システム・ロードはファイル転送プロセスとinitializerプロセスに制限されました。 かなり短いケーブル(長さおよそ100フィートの)によってMIT MulticsはIMP No.44(ポート0)に接続されます。 CISL Multicsはl5OOおよそ長さ足のケーブルによってIMP No.6(ポート0)に接続されます。 8oth IMPsは厳密な体と体の接近(およそ2000フィート)にはあって、5Oによって1セカンドラインあたりのキロビットに互いに接続されます。 上に与えられた結果は新しいIMP DIMとの性能にかなりの改良を示しています。

Since there is considerable interest in the Multics development community in
using the file transfer facility for transmitting Multics System Tapes between
the two systems, we are providing here an estimate of time that would be taken
to transmit the current MST. MST 23.4-0A contains 334,231 words. When
multiplied by 36 (the word length in bits) this yields the total number of bits
to be approximately 12.5 million. Assuming a file transfer rate of 27,500 bits
per second, it will take approximately 7 minutes and 30 seconds to transmit the
system 23.4-0A.

2台のシステムの間にMultics System Tapesを伝えるのにファイル転送施設を使用するのにおいてMultics開発共同体への相当な興味があるので、私たちは現在のMST. MST23.4-0を伝えるにはかかる時間の見積りをここに提供しています。Aは33万4231の単語を含んでいます。 36(ビットの語長)によって掛けられると、これは、およそ1250万になるようにビットの総数をもたらします。 2万7500のbpsのファイル転送率を仮定すると、システム23.4-0Aを伝えるにはおよそ7分と30秒かかるでしょう。

In the experiment outlined above, there was only one file being transferred at
any given tine between the two systems. We conducted another experiment to get
an estimate of performance in the situation of multiple file transfers occurring
simultaneously. This experiment consisted of first two, and then three,
simultaneous file-transfers from the development system to the service system.
These file transfers were started by different processes logged in from separate
consoles. Because these file-transfers were started manually, we could not
obtain perfect simultaneity and results obtained for the total bandwidth are
essentially approximate. For two simultaneous file transfers the total bit rate
was approximately 40,000 bits per second and bit rate for each file transfer was
approximately 20,000 bits per second. For three simultaneous file transfers,
total bit rate remained at approximately 40,000 bits per second and bit rate for
individual transfers was approximately 13,500 bits per second.

上に概説された実験には、2台のシステムの間には、どんな与えられた歯でも移される1個のファイルしかありませんでした。私たちは、複数のファイル転送の状況における、性能の見積りを同時に起こらせるように別の実験を行いました。 この実験は開発システムからサービス・システムまでの最初に、2、および次に、3、同時のファイル転送から成りました。 これらのファイル転送はログインされた別々のコンソールと異なったプロセスによって始められました。 これらのファイル転送が手動で始められたので、私たちは完全な同時性を得ることができませんでした、そして、総帯域幅に得られた結果は本質的には大体です。 2つの同時のファイル転送のために、総ビット伝送速度はおよそ4万のbpsでした、そして、各ファイル転送のためのビット伝送速度はおよそ2万のbpsでした。 3つの同時のファイル転送のために、総ビット伝送速度はおよそ4万のbpsに残りました、そして、個々の転送のためのビット伝送速度はおよそ1万3500のbpsでした。

                                      -3-

-3-