RFC1030 日本語訳
1030 On testing the NETBLT Protocol over divers networks. M.L.Lambert. November 1987. (Format: TXT=40964 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Lambert
Request for Comments: 1030 M.I.T. Laboratory for Computer Science
November 1987
コメントを求めるワーキンググループM.ランバート要求をネットワークでつないでください: 1030 マサチューセッツ工科大学コンピュータ科学研究所1987年11月
On Testing the NETBLT Protocol over Divers Networks
幾つかのネットワークの上でNETBLTプロトコルをテストすることに関して
STATUS OF THIS MEMO
このメモの状態
This RFC describes the results gathered from testing NETBLT over three networks of differing bandwidths and round-trip delays. While the results are not complete, the information gathered so far has been very promising and supports RFC-998's assertion that that NETBLT can provide very high throughput over networks with very different characteristics. Distribution of this memo is unlimited.
このRFCは異なった帯域幅と往復の遅れのテストNETBLTより多くのthreeネットワークから集められた結果について説明します。 結果は完全ではありませんが、今までのところ集められている情報は、非常に有望であり、そのNETBLTがネットワークの上の非常に高いスループットに非常に異なった特性を提供できるというRFC-998の主張をサポートします。 このメモの分配は無制限です。
1. Introduction
1. 序論
NETBLT (NETwork BLock Transfer) is a transport level protocol intended for the rapid transfer of a large quantity of data between computers. It provides a transfer that is reliable and flow controlled, and is designed to provide maximum throughput over a wide variety of networks. The NETBLT protocol is specified in RFC-998; this document assumes an understanding of the specification as described in RFC-998.
NETBLT(NETwork BLock Transfer)は平らなプロトコルがコンピュータの間の多量のデータの迅速な移転のために意図した輸送です。 それが信頼できる転送を供給して、流れは、制御して、さまざまなネットワークの上に最大のスループットを提供するように設計されています。 NETBLTプロトコルはRFC-998で指定されます。 このドキュメントはRFC-998で説明されるように仕様の理解を仮定します。
Tests over three different networks are described in this document. The first network, a 10 megabit-per-second Proteon Token Ring, served as a "reference environment" to determine NETBLT's best possible performance. The second network, a 10 megabit-per-second Ethernet, served as an access path to the third network, the 3 megabit-per- second Wideband satellite network. Determining NETBLT's performance over the Ethernet allowed us to account for Ethernet-caused behaviour in NETBLT transfers that used the Wideband network. Test results for each network are described in separate sections. The final section presents some conclusions and further directions of research. The document's appendices list test results in detail.
3つの異なったネットワークの上のテストは本書では説明されます。 最初のネットワーク(10 1秒あたりのメガビットProteon Token Ring)はNETBLTの可能な限り良い性能を決定する「参照環境」として機能しました。 2番目のネットワーク(10の1秒あたりのメガビットイーサネット)はアクセス経路として3番目のネットワーク(3第2Widebandあたりのメガビット衛星ネットワーク)に機能しました。 イーサネットの上のNETBLTの性能を決定するのに、私たちはWidebandネットワークを使用したNETBLT転送におけるイーサネットで引き起こされたふるまいを説明できました。 各ネットワークのための試験の成績は別々のセクションで説明されます。 最後のセクションは研究に関するいくつかの結論と続行を提示します。 ドキュメントの付録は詳細に試験の成績を記載します。
2. Acknowledgements
2. 承認
Many thanks are due Bob Braden, Stephen Casner, and Annette DeSchon of ISI for the time they spent analyzing and commenting on test results gathered at the ISI end of the NETBLT Wideband network tests. Bob Braden was also responsible for porting the IBM PC/AT NETBLT implementation to a SUN-3 workstation running UNIX. Thanks are also due Mike Brescia, Steven Storch, Claudio Topolcic and others at BBN who provided much useful information about the Wideband network, and
ありがとうございます、彼らが過ごした時間のNETBLT WidebandネットワークテストのISIエンドに集められた試験の成績を分析して、批評するISIの当然のボブ・ブレーデン、スティーブンCasner、およびアネットDeSchonはそうですか? また、ボブ・ブレーデンもUNIXを実行しながらIBM PC/AT NETBLT実装をSUN-3ワークステーションに移植するのに責任がありました。 そして感謝がWidebandネットワークに関する多くの役に立つ情報を提供したBBNの当然のマイク・ブレシアとも、スティーブン・シュトルヒと、クラウディオTopolcicと他のものである。
M. Lambert [Page 1] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[1ページ]RFC1030
helped monitor it during testing.
テストの間、それをモニターするのを助けました。
3. Implementations and Test Programs
3. 実装とテストプログラム
This section briefly describes the NETBLT implementations and test programs used in the testing. Currently, NETBLT runs on three machine types: Symbolics LISP machines, IBM PC/ATs, and SUN-3s. The test results described in this paper were gathered using the IBM PC/AT and SUN-3 NETBLT implementations. The IBM and SUN implementations are very similar; most differences lie in timer and multi-tasking library implementations. The SUN NETBLT implementation uses UNIX's user-accessible raw IP socket; it is not implemented in the UNIX kernel.
このセクションは簡潔にテストで使用されるNETBLT実装とテストプログラムについて説明します。 現在、NETBLTは3つのマシンタイプで動きます: 信条学LISPマシン、IBM PC/ATs、およびSUN-3s。 この紙で説明された試験の成績は、IBM PC/ATとSUN-3 NETBLT実装を使用することで集められました。 IBMとSUN実装は非常に同様です。 タイマと多重タスキングライブラリ実装にはほとんどの違いがあります。 SUN NETBLT実装はUNIXのユーザアクセスしやすい生のIPソケットを使用します。 それはUNIXカーネルで実装されません。
The test application performs a simple memory-to-memory transfer of an arbitrary amount of data. All data are actually allocated by the application, given to the protocol layer, and copied into NETBLT packets. The results are therefore fairly realistic and, with appropriately large amounts of buffering, could be attained by disk- based applications as well.
テストアプリケーションは簡単な任意のデータ量のメモリから転記を実行します。 すべてのデータが、実際にプロトコル層に与えられたアプリケーションで割り当てられて、NETBLTパケットにコピーされます。 適切に多量のバッファリングで、結果は、したがって、かなり現実的であり、ディスクまた、ベースのアプリケーションで達するかもしれません。
The test application provides several parameters that can be varied to alter NETBLT's performance characteristics. The most important of these parameters are:
テストアプリケーションはNETBLTの性能の特性を変更するために変えることができるいくつかのパラメタを提供します。 これらのパラメタで最も重要であるのは、以下の通りです。
burst interval The number of milliseconds from the start of one
burst transmission to the start of the next burst
transmission.
1の始まりからのミリセカンドの数がトランスミッションを次のバースト伝送の始まりまで押し破いた間隔を押し破いてください。
burst size The number of packets transmitted per burst.
パケットの数が炸裂単位で伝えたサイズを押し破いてください。
buffer size The number of bytes in a NETBLT buffer (all
buffers must be the same size, save the last,
which can be any size required to complete the
transfer).
NETBLTのバイト数がバッファリングするサイズをバッファリングしてください(すべてのバッファが同じサイズであるに違いなく、転送を終了するのに必要であるサイズであるかもしれない最終を節約してください)。
data packet size
The number of bytes contained in a NETBLT DATA
packet's data segment.
バイト数がNETBLT DATAパケットのデータ・セグメントに含んだデータ・パケットサイズ。
number of outstanding buffers
The number of buffers which can be in
transmission/error recovery at any given moment.
傑出することの数はトランスミッション/エラー回復にいつなんどきでもあることができるバッファの数をバッファリングします。
M. Lambert [Page 2] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[2ページ]RFC1030
The protocol's throughput is measured in two ways. First, the "real throughput" is throughput as viewed by the user: the number of bits transferred divided by the time from program start to program finish. Although this is a useful measurement from the user's point of view, another throughput measurement is more useful for analyzing NETBLT's performance. The "steady-state throughput" is the rate at which data is transmitted as the transfer size approaches infinity. It does not take into account connection setup time, and (more importantly), does not take into account the time spent recovering from packet-loss errors that occur after the last buffer in the transmission is sent out. For NETBLT transfers using networks with long round-trip delays (and consequently with large numbers of outstanding buffers), this "late" recovery phase can add large amounts of time to the transmission, time which does not reflect NETBLT's peak transmission rate. The throughputs listed in the test cases that follow are all steady-state throughputs.
プロトコルのスループットは2つの方法で測定されます。 まず最初に、ユーザによって見られるように「本当のスループット」はスループットです: ビットの数は時間によってプログラム・スタートからプログラムの終わりまで分割されていた状態で移されました。 これはユーザの観点からの役に立つ測定ですが、別のスループット測定はNETBLTの性能を分析するのにより役に立ちます。 「定常状態スループット」は転送サイズが無限にアプローチするのに応じてデータが送られるレートです。 そして、それが接続準備時間を考慮に入れない、(より重要)、トランスミッションにおける最後のバッファを出した後に発生するパケット損失誤りから克服しながら費やされた時間に考慮に入れないでください。 NETBLTに関しては、転送が長い往復の遅れ(そしてその結果多くの傑出しているバッファで)があるネットワークを使用して、この「遅い」回収段階はトランスミッション(NETBLTのピーク通信速度を反映しない時間)に多量の時間を加えることができます。 従うテストケースでリストアップされたスループットはすべて定常状態スループットです。
4. Implementation Performance
4. 実装パフォーマンス
This section describes the theoretical performance of the IBM PC/AT NETBLT implementation on both the transmitting and receiving sides. Theoretical performance was measured on two LANs: a 10 megabit-per- second Proteon Token Ring and a 10 megabit-per-second Ethernet. "Theoretical performance" is defined to be the performance achieved if the sending NETBLT did nothing but transmit data packets, and the receiving NETBLT did nothing but receive data packets.
このセクションは両方の伝えるのと受信側におけるIBM PC/AT NETBLT実装の理論上の性能について説明します。 理論上の性能は2つのLANで測定されました: 第2Proteon Token Ringあたり1つの10メガビットと10の1秒あたりのメガビットイーサネット。 「理論上の性能」は、発信しているNETBLTがデータ・パケットを送信しただけであり、受信NETBLTがデータ・パケットを受けただけであるなら達成された性能になるように定義されます。
Measuring the send-side's theoretical performance is fairly easy, since the sending NETBLT does very little more than transmit packets at a predetermined rate. There are few, if any, factors which can influence the processing speed one way or another.
側のものを発信させている理論上の性能を測定するのはかなり簡単です、発信しているNETBLTが予定率でパケットを伝えるよりほとんどさらにしないので。 処理に影響を及ぼすことができる要素がいずれにしてもいくらか疾走するなら、わずか、があります。
Using a Proteon P1300 interface on a Proteon Token Ring, the IBM PC/AT NETBLT implementation can copy a maximum-sized packet (1990 bytes excluding protocol headers) from NETBLT buffer to NETBLT data packet, format the packet header, and transmit the packet onto the network in about 8 milliseconds. This translates to a maximum theoretical throughput of 1.99 megabits per second.
Proteon Token RingでProteon P1300インタフェースを使用して、IBM PC/AT NETBLT実装は、およそ8ミリセカンドでネットワークにNETBLTからの(プロトコルヘッダーを除いた1990バイト)がNETBLTデータ・パケットにバッファリングする最大サイズのパケットをコピーして、パケットのヘッダーをフォーマットして、パケットを伝えることができます。 これは1秒あたり1.99のメガビットの最大の理論上のスループットに翻訳されます。
Using a 3COM 3C500 interface on an Ethernet LAN, the same implementation can transmit a maximum-sized packet (1438 bytes excluding protocol headers) in 6.0 milliseconds, for a maximum theoretical throughput of 1.92 megabits per second.
イーサネットLANで3COM 3C500インタフェースを使用して、同じ実装は6.0ミリセカンドで最大サイズのパケット(プロトコルヘッダーを除いた1438バイト)を伝えることができます、1秒あたり1.92のメガビットの最大の理論上のスループットのために。
Measuring the receive-side's theoretical performance is more difficult. Since all timer management and message ACK overhead is incurred at the receiving NETBLT's end, the processing speed can be slightly slower than the sending NETBLT's processing speed (this does
側のものを受け取っている理論上の性能を測定するのは、より難しいです。 すべてのタイマ管理とメッセージACKオーバーヘッドが受信NETBLTの終わりに被られるので、処理速度が発信しているNETBLTが速度を処理するよりわずかに遅い場合がある、(これはします。
M. Lambert [Page 3] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[3ページ]RFC1030
not even take into account the demultiplexing overhead that the receiver incurs while matching packets with protocol handling functions and connections). In fact, the amount by which the two processing speeds differ is dependent on several factors, the most important of which are: length of the NETBLT buffer list, the number of data timers which may need to be set, and the number of control messages which are ACKed by the data packet. Almost all of this added overhead is directly related to the number of outstanding buffers allowable during the transfer. The fewer the number of outstanding buffers, the shorter the NETBLT buffer list, and the faster a scan through the buffer list and the shorter the list of unacknowledged control messages.
頭上のプロトコル取り扱いにパケットを合わせるのが機能しますが、受信機が被る逆多重化と接続が考慮に入れてさえいない、) 事実上、量は2つの処理速度が異なるいくつかの要素に依存しています、どれが以下の通りかに、最も重要です。 NETBLTバッファリストの長さ、設定される必要があるかもしれないデータタイマの数、およびデータ・パケットによるACKedであるコントロールメッセージの数。 このほとんどすべてが、オーバーヘッドが直接転送の間、許容できる傑出しているバッファの数に関連すると言い足しました。 傑出しているバッファの数が少なければ少ないほど、不承認のコントロールメッセージのリストは、NETBLTがリストをバッファリングして、バッファリストを通したスキャンが速ければ速いほど、より短くて、より短いです。
Assuming a single-outstanding-buffer transfer, the receiving-side NETBLT can DMA a maximum-sized data packet from the Proteon Token Ring into its network interface, copy it from the interface into a packet buffer and finally copy the packet into the correct NETBLT buffer in 8 milliseconds: the same speed as the sender of data.
ネットワークへのProteon Token Ringからの最大サイズのデータ・パケットが連結するDMA、ただ一つの傑出しているバッファ転送、受信サイドNETBLTがそうすることができると仮定して、インタフェースからパケットバッファの中にそれをコピーしてください、そして、8ミリセカンドに最終的に正しいNETBLTバッファの中にパケットをコピーしてください: データの送付者と同じ速度。
Under the same conditions, the implementation can receive a maximum- sized packet from the Ethernet in 6.1 milliseconds, for a maximum theoretical throughput of 1.89 megabits per second.
同じ条件のもとでは、実装は6.1ミリセカンドでイーサネットから最大の大きさで分けられたパケットを受けることができます、1秒あたり1.89のメガビットの最大の理論上のスループットのために。
5. Testing on a Proteon Token Ring
5. Proteonトークンリングの上でテストすること。
The Proteon Token Ring used for testing is a 10 megabit-per-second LAN supporting about 40 hosts. The machines on either end of the transfer were IBM PC/ATs using Proteon P1300 network interfaces. The Token Ring provides high bandwidth with low round-trip delay and negligible packet loss, a good debugging environment in situations where packet loss, packet reordering, and long round-trip time would hinder debugging. Also contributing to high performance is the large (maximum 2046 bytes) network MTU. The larger packets take somewhat longer to transmit than do smaller packets (8 milliseconds per 2046 byte packet versus 6 milliseconds per 1500 byte packet), but the lessened per-byte computational overhead increases throughput somewhat.
テストするのに使用されるProteon Token Ringはおよそ40人のホストをサポートする10 1秒あたりのメガビットLANです。 転送のどちらかの終わりのマシンはProteon P1300ネットワーク・インターフェースを使用するIBM PC/ATsでした。 Token Ringは低い往復の遅れと取るにたらないパケット損失(パケット損失、パケット再命令、および長い往復の時間がデバッグするのを妨げる状況における良いデバッグ環境)に高帯域を提供します。 また、高性能に貢献するのは、大きい(最大の2046バイト)ネットワークMTUです。 より小さいパケット(2046年のバイトのパケットあたり8ミリセカンド対1500年のバイトのパケットあたり6ミリセカンド)より大きいパケットに伝わるようにいくらか時間がかかりますが、1バイトあたりの少なくなっているコンピュータのオーバーヘッドはスループットをいくらか増強します。
The fastest single-outstanding-buffer transmission rate was 1.49 megabits per second, and was achieved using a test case with the following parameters:
最も速いただ一つの傑出しているバッファ通信速度は、1秒あたり1.49のメガビットであり、以下のパラメタでテストケースを使用することで達成されました:
M. Lambert [Page 4] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[4ページ]RFC1030
transfer size 2-5 million bytes
サイズを2-500万バイト移してください。
data packet size
1990 bytes
1990バイトのデータ・パケットサイズ
buffer size 19900 bytes
19900バイトのバッファサイズ
burst size 5 packets
放出量5パケット
burst interval 40 milliseconds. The timer code on the IBM PC/AT
is accurate to within 1 millisecond, so a 40
millisecond burst can be timed very accurately.
間隔を40ミリセカンドと同じくらい押し破いてください。 IBM PC/ATのタイマコードが1ミリセカンドに正確であるので、非常に正確に40ミリセカンドの炸裂を調節できます。
Allowing only one outstanding buffer reduced the protocol to running "lock-step" (the receiver of data sends a GO, the sender sends data, the receiver sends an OK, followed by a GO for the next buffer). Since the lock-step test incurred one round-trip-delay's worth of overhead per buffer (between transmission of a buffer's last data packet and receipt of an OK for that buffer/GO for the next buffer), a test with two outstanding buffers (providing essentially constant packet transmission) should have resulted in higher throughput.
1つの傑出しているバッファだけを許容すると、プロトコルは実行している「型にはまったやり方」に減少しました(データの受信機はGOを送って、送付者はデータを送って、受信機は次のバッファのためにGOによって続かれたOKを送ります)。 堅苦しいテストが1つの往復の遅れのバッファ(バッファの最後のデータ・パケットのトランスミッションと次のバッファのためのそのバッファ/GOのためのOKの受領の間の)あたりのオーバーヘッドの価値を被ったので、2つの傑出しているバッファ(本質的には一定のパケット伝送を提供する)があるテストは、より高いスループットをもたらすべきでした。
A second test, this time with two outstanding buffers, was performed, with the above parameters identical save for an increased burst interval of 43 milliseconds. The highest throughput recorded was 1.75 megabits per second. This represents 95% efficiency (5 1990- byte packets every 43 milliseconds gives a maximum theoretical throughput of 1.85 megabits per second). The increase in throughput over a single-outstanding-buffer transmission occurs because, with two outstanding buffers, there is no round-trip-delay lag between buffer transmissions and the sending NETBLT can transmit constantly. Because the P1300 interface can transmit and receive concurrently, no packets were dropped due to collision on the interface.
2番目のテスト(2つの傑出しているバッファがある今回)は実行されました、43ミリセカンドの増強された炸裂間隔を除いて、同じ上記のパラメタで。 記録される中で最も高いスループットは1秒あたり1.75のメガビットでした。 これは95%の効率(43ミリセカンド毎が1秒あたり1.85のメガビットの最大の理論上のスループットに与える5 1990バイトパケット)を表します。 NETBLTが絶えず伝えることができるバッファトランスミッションと発信の間には、往復の遅れ立ち遅れが全く2つの傑出しているバッファと共にないので、ただ一つの傑出しているバッファトランスミッションの上のスループットの増加は起こります。 P1300インタフェースが同時に送受信されることができて、パケットは全く衝突のためインタフェースで下げられませんでした。
As mentioned previously, the minimum transmission time for a maximum-sized packet on the Proteon Ring is 8 milliseconds. One would expect, therefore, that the maximum throughput for a double- buffered transmission would occur with a burst interval of 8 milliseconds times 5 packets per burst, or 40 milliseconds. This would allow the sender of data to transmit bursts with no "dead time" in between bursts. Unfortunately, the sender of data must take time to process incoming control messages, which typically forces a 2-3 millisecond gap between bursts, lowering the throughput. With a burst interval of 43 milliseconds, the incoming packets are processed
既述のとおり、Proteon Ringの上の最大サイズのパケットのための最小のトランスミッション時間は8ミリセカンドです。 したがって、人は、二重バッファリングされたトランスミッションのための最大のスループットが8ミリセカンドの回の炸裂間隔で1炸裂あたり5つのパケット、または40ミリセカンドと同じくらい現れると予想するでしょう。 これで、データの送付者は「不動作時間」なしで炸裂の間に炸裂を伝えることができるでしょう。 残念ながら、データの送付者は入って来るコントロールメッセージを処理するために時間をかけなければなりません(炸裂の2-3ミリセカンドのギャップを通常強制します)、スループットを下げて。 43ミリセカンドの炸裂間隔で、入って来るパケットは処理されます。
M. Lambert [Page 5] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[5ページ]RFC1030
during the 3 millisecond-per-burst "dead time", making the protocol more efficient.
1炸裂あたり3ミリセカンド、プロトコルをより効率的にする「不動作時間。」
6. Testing on an Ethernet
6. イーサネットではテストすること。
The network used in performing this series of tests was a 10 megabit per second Ethernet supporting about 150 hosts. The machines at either end of the NETBLT connection were IBM PC/ATs using 3COM 3C500 network interfaces. As with the Proteon Token Ring, the Ethernet provides high bandwidth with low delay. Unfortunately, the particular Ethernet used for testing (MIT's infamous Subnet 26) is known for being somewhat noisy. In addition, the 3COM 3C500 Ethernet interfaces are relatively unsophisticated, with only a single hardware packet buffer for both transmitting and receiving packets. This gives the interface an annoying tendency to drop packets under heavy load. The combination of these factors made protocol performance analysis somewhat more difficult than on the Proteon Ring.
およそ150人のホストをサポートする第2イーサネットあたりこのシリーズのテストを実行する際に使用されるネットワークは1つの10メガビットでした。 NETBLT接続のどちらかの終わりのマシンは3COM 3C500ネットワーク・インターフェースを使用するIBM PC/ATsでした。 Proteon Token Ringのように、イーサネットは低い遅れを高帯域に提供します。 残念ながら、テストするのに使用される特定のイーサネット(MITの悪名高いSubnet26)は、いくらか騒がしいので、知られています。 さらに、3COM 3C500イーサネットインタフェースは比較的世慣れていないです、両方のためのただ一つのハードウェアパケットバッファだけがパケットを送信して、受けていて。 これは重量物の下でパケットを下げる煩わしい傾向をインタフェースに与えます。 これらの要素の組み合わせで、プロトコル機能解析はProteon Ringよりいくらか難しくなりました。
The fastest single-buffer transmission rate was 1.45 megabits per second, and was achieved using a test case with the following parameters:
最も速いただ一つのバッファ通信速度は、1秒あたり1.45のメガビットであり、以下のパラメタでテストケースを使用することで達成されました:
transfer size 2-5 million bytes
サイズを2-500万バイト移してください。
data packet size
1438 bytes (maximum size excluding protocol
headers).
1438バイト(プロトコルヘッダーを除いた最大サイズ)のデータ・パケットサイズ。
buffer size 14380 bytes
14380バイトのバッファサイズ
burst size 5 packets
放出量5パケット
burst interval 30 milliseconds (6.0 milliseconds x 5 packets).
間隔を30ミリセカンド(6.0ミリセカンドx5パケット)と同じくらい押し破いてください。
A second test, this one with parameters identical to the first save for number of outstanding buffers (2 instead of 1) resulted in substantially lower throughput (994 kilobits per second), with a large number of packets retransmitted (10%). The retransmissions occurred because the 3COM 3C500 network interface has only one hardware packet buffer and cannot hold a transmitting and receiving packet at the same time. With two outstanding buffers, the sender of data can transmit constantly; this means that when the receiver of data attempts to send a packet, its interface's receive hardware goes
2番目のテスト、傑出しているバッファ(1の代わりに2)の数を除いて、1日と同じパラメタに従ったこれは実質的に低いスループット(1秒あたり994のキロビット)をもたらしました、多くのパケットが再送されている状態で(10%)。 「再-トランスミッション」は、3COM 3C500ネットワーク・インターフェースには1つのハードウェアパケットバッファしかないので起こって、同時に、伝えるのと受信パケットを開催できません。 2つの傑出しているバッファで、データの送付者は絶えず伝わることができます。 パケット、インタフェースのものを送るデータ試みの受信機であるときにハードウェアを受け止めるこの手段が行きます。
M. Lambert [Page 6] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[6ページ]RFC1030
deaf to the network and any packets being transmitted at the time by the sender of data are lost. A symmetrical problem occurs with control messages sent from receiver of data to sender of data, but the number of control messages sent is small enough and the retransmission algorithm redundant enough that little performance degradation occurs due to control message loss.
失われたデータの送付者によって当時、伝えられるネットワークとどんなパケットにも、耳を傾けません。 対称の問題はデータの受信機からデータの送付者にコントロールメッセージを送って起こりますが、メッセージが送ったコントロールの数は十分少なく、再送信アルゴリズムは性能退行がコントロールメッセージの損失のためほとんど起こらないほど余分です。
When the burst interval was lengthened from 30 milliseconds per 5 packet burst to 45 milliseconds per 5 packet burst, a third as many packets were dropped, and throughput climbed accordingly, to 1.12 megabits per second. Presumably, the longer burst interval allowed more dead time between bursts and less likelihood of the receiver of data's interface being deaf to the net while the sender of data was sending a packet. An interesting note is that, when the same test was conducted on a special Ethernet LAN with the only two hosts attached being the two NETBLT machines, no packets were dropped once the burst interval rose above 40 milliseconds/5 packet burst. The improved performance was doubtless due to the absence of extra network traffic.
炸裂間隔が5パケット炸裂あたり45ミリセカンドまで押し破かれた5パケットあたり30ミリセカンドから伸されたとき、3分の1同じくらい多くのパケットが下げられました、そして、スループットはそれに従って、登りました、1秒あたり1.12のメガビットに。 おそらく、より長い炸裂間隔はデータのデータの送付者がパケットを送った間ネットに耳を傾けないインタフェースの受信機の炸裂と、より少ない見込みの間により多くの不動作時間を許容しました。 おもしろい注意がそれである、同じテストが特別なイーサネットLANで唯一で行われたとき、2台のNETBLTマシンであるので、2人のホストが付いて、炸裂間隔が40ミリセカンド/5のパケット炸裂の上でいったん上昇すると、パケットは全く下げられませんでした。 向上した性能は付加的なネットワークトラフィックの不在のために疑いなかったです。
7. Testing on the Wideband Network
7. 広帯域ネットワークではテストすること。
The following section describes results gathered using the Wideband network. The Wideband network is a satellite-based network with ten stations competing for a raw satellite channel bandwidth of 3 megabits per second. Since the various tests resulted in substantial changes to the NETBLT specification and implementation, some of the major changes are described along with the results and problems that forced those changes.
以下のセクションはWidebandネットワークを使用することで集められた結果について説明します。 Widebandネットワークは10のステーションが1秒あたり3つのメガビットの生の衛星チャンネル帯域幅を競争している衛星を拠点とするネットワークです。 様々なテストがNETBLT仕様と実装への大きな変化をもたらしたので、いくつかの大きな変化がそれらの変化を強制した結果と問題と共に説明されます。
The Wideband network has several characteristics that make it an excellent environment for testing NETBLT. First, it has an extremely long round-trip delay (1.8 seconds). This provides a good test of NETBLT's rate control and multiple-buffering capabilities. NETBLT's rate control allows the packet transmission rate to be regulated independently of the maximum allowable amount of outstanding data, providing flow control as well as very large "windows". NETBLT's multiple-buffering capability enables data to still be transmitted while earlier data are awaiting retransmission and subsequent data are being prepared for transmission. On a network with a long round-trip delay, the alternative "lock-step" approach would require a 1.8 second gap between each buffer transmission, degrading performance.
Widebandネットワークには、テストNETBLTのためにそれを素晴らしい環境にするいくつかの特性があります。 まず最初に、それには、非常に長い往復の遅れ(1.8秒)があります。 これはNETBLTの速度制御と倍数をバッファリングする能力の良いテストを提供します。 NETBLTの速度制御は、パケット伝送レートが最大の許容できる量の傑出しているデータの如何にかかわらず規制されるのを許容します、非常に大きい「窓」と同様にフロー制御を提供して。 以前のデータが「再-トランスミッション」を待っていて、順次データがトランスミッションのために準備されている間、NETBLTの倍数をバッファリングする能力は、データがまだ送られているのを可能にします。 長い往復の遅れ、代替手段がある「堅苦しい」アプローチがそれぞれ1.8 2番目のギャップを必要とするネットワークでは、トランスミッションをバッファリングしてください、性能を下げて。
Another interesting characteristic of the Wideband network is its throughput. Although its raw bandwidth is 3 megabits per second, at the time of these tests fully 2/3 of that was consumed by low-level network overhead and hardware limitations. (A detailed analysis of
Widebandネットワークの別のおもしろい特性はそのスループットです。 生の帯域幅は1秒あたり3つのメガビットですが、これらのテスト時点で、完全に、その2/3は低レベルであるネットワークオーバーヘッドとハードウェア制限で消費されました。 (Aは分析を詳しく述べました。
M. Lambert [Page 7] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[7ページ]RFC1030
the overhead appears at the end of this document.) This reduces the available bandwidth to just over 1 megabit per second. Since the NETBLT implementation can run substantially faster than that, testing over the Wideband net allows us to measure NETBLT's ability to utilize very high percentages of available bandwidth.
オーバーヘッドはこのドキュメントの端に現れます。) これは利用可能な帯域幅を1秒あたりちょうど1つ以上のメガビットまで減少させます。 NETBLT実装が実質的にそれより速く動くことができるので、Widebandネットの上でテストするのに、私たちは非常に高い百分率の利用可能な帯域幅を利用するNETBLTの性能を測定できます。
Finally, the Wideband net has some interesting packet reorder and delay characteristics that provide a good test of NETBLT's ability to deal with these problems.
最終的に、Widebandネットには、これらの問題に対処するNETBLTの性能の良いテストを提供するいくつかのおもしろいパケット追加注文と遅れの特性があります。
Testing progressed in several phases. The first phase involved using source-routed packets in a path from an IBM PC/AT on MIT's Subnet 26, through a BBN Butterfly Gateway, over a T1 link to BBN, onto the Wideband network, back down into a BBN Voice Funnel, and onto ISI's Ethernet to another IBM PC/AT. Testing proceeded fairly slowly, due to gateway software and source-routing bugs. Once a connection was finally established, we recorded a best throughput of approximately 90K bits per second.
テストはいくつかのフェーズに進歩しました。 第1段階は、T1リンクの上に経路でMITのSubnet26の上のIBM PC/ATからBBN Butterflyゲートウェイまでソースによって発送されたパケットを使用することをBBNと、そして、BBN Voice FunnelへのWidebandネットワークと別のIBM PC/ATへのISIのイーサネットに伴いました。 ゲートウェイソフトウェアとソースルーティングバグのためかなりゆっくりテストしかけました。 接続がいったん最終的に確立されると、私たちはおよそ90Kのbpsの最も良い効率を記録しました。
Several problems contributed to the low throughput. First, the gateways at either end were forwarding packets onto their respective LANs faster than the IBM PC/AT's could accept them (the 3COM 3C500 interface would not have time to re-enable input before another packet would arrive from the gateway). Even with bursts of size 1, spaced 6 milliseconds apart, the gateways would aggregate groups of packets coming from the same satellite frame, and send them faster than the PC could receive them. The obvious result was many dropped packets, and degraded performance. Also, the half-duplex nature of the 3COM interface caused incoming packets to be dropped when packets were being sent.
いくつかの問題が少ないスループットに貢献しました。 まず最初に、どちらかの終わりのゲートウェイはIBM ATのPC/ものがそれらを受け入れることができたより(3COM 3C500インタフェースには、別のパケットがゲートウェイから到着する前に入力を再可能にする時間がないでしょう)速くそれらのそれぞれのLANにパケットを送っていました。 6ミリセカンドと同じくらい離れて区切られたサイズ1の炸裂があっても、ゲートウェイはPCがそれらを受けることができたより速くそれらを送りに同じ衛星フレームから来るパケットのグループに集められるでしょう。 明白な結果は、多くの下げられたパケットであり、性能を下げました。 また、パケットを送ったとき、3COMインタフェースの半二重自然は入って来るパケットを下げさせました。
The number of packets dropped on the sending NETBLT side due to the long interface re-enable time was reduced by packing as many control messages as possible into a single control packet (rather than placing only one message in a control packet). This reduced the number of control packets transmitted to one per buffer transmission, which the PC was able to handle. In particular, messages of the form OK(n) were combined with messages of the form GO(n + 1), in order to prevent two control packets from arriving too close together to both be received.
長いインタフェースのため送付NETBLT側で下げられたパケットの数は時間を再可能にします。単一管理パケット(1つのメッセージだけをコントロールパケットに置くよりむしろ)にできるだけ多くのコントロールメッセージに詰め込むことによって、短縮されました。 これはPCが扱うことができたバッファトランスミッションあたり1つに伝えられたコントロールパケットの数を減少させました。 特に、フォームOK(n)に関するメッセージはフォームGO(n+1)に関するメッセージに結合されました、2つのコントロールパケットがともに受け取るためにあまりに近くに一緒に到着するのを防ぐために。
Performance degradation from dropped control packets was also minimized by changing to a highly redundant control packet transmission algorithm. Control messages are now stored in a single long-lived packet, with ACKed messages continuously bumped off the head of the packet and new messages added at the tail of the packet. Every time a new message needs to be transmitted, any unACKed old messages are transmitted as well. The sending NETBLT, which receives
また、下げられたコントロールパケットからのパフォーマンス退行は、非常に余分なコントロールパケット伝送アルゴリズムに変化することによって、最小にされました。 コントロールメッセージは現在単一の長命のパケットに保存されます、ACKedメッセージがパケットのヘッドで絶え間なく突き当たられていて、新しいメッセージがパケットのテールで加えられている状態で。 また、伝えられるのが必要であるときはいつも、どんなunACKedの古いメッセージも送られます。 発信しているNETBLT。(そのNETBLTは受信します)。
M. Lambert [Page 8] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[8ページ]RFC1030
these control messages, is tuned to ignore duplicate messages with almost no overhead. This transmission redundancy puts little reliance on the NETBLT control timer, further reducing performance degradation from lost control packets.
これらは、メッセージを制御して、ほとんどオーバーヘッドがない写しメッセージを無視するために調整されます。 さらに無くなっているコントロールパケットからの性能退行を抑えて、このトランスミッション冗長はほとんどNETBLT制御タイマに信用を置きません。
Although the effect of dropped packets on the receiving NETBLT could not be completely eliminated, it was reduced somewhat by some changes to the implementation. Data packets from the sending NETBLT are guaranteed to be transmitted by buffer number, lowest number first. In some cases, this allowed the receiving NETBLT to make retransmit- request decisions for a buffer N, if packets for N were expected but none were received at the time packets for a buffer N+M were received. This optimization was somewhat complicated, but improved NETBLT's performance in the face of missing packets. Unfortunately, the dropped-packet problem remained until the NETBLT implementation was ported to a SUN-3 workstation. The SUN is able to handle the incoming packets quite well, dropping only 0.5% of the data packets (as opposed to the PC's 15 - 20%).
完全に受信NETBLTへの下げられたパケットの効果を排除できたというわけではありませんが、それはいくらか実装へのいくつかの変化によって減少させられました。 発信しているNETBLTからのデータ・パケットは、最初にバッファ数、最も下位の数によって伝えられるために保証されます。 いくつかの場合、これで、Nのためのパケットが予想されましたが、なにもバッファのために時間パケットに受け取られなかったなら、受信NETBLTがバッファNのための要求決定を再送するのをN+Mを受け取らせることができました。 この最適化はなくなったパケットに直面していくらか複雑な、しかし、改良されたNETBLTの性能でした。 残念ながら、下げられたパケット問題はSUN-3ワークステーションにNETBLT実装を移植するまで残っていました。 と対照的に、SUNが入って来るパケットを全くよく扱うことができて、唯一の低下がデータ・パケットの0.5%である、(PC15--20%)
Another problem with the Wideband network was its tendency to re- order and delay packets. Dealing with these problems required several changes in the implementation. Previously, the NETBLT implementation was "optimized" to generate retransmit requests as soon as possible, if possible not relying on expiration of a data timer. For instance, when the receiving NETBLT received an LDATA packet for a buffer N, and other packets in buffer N had not arrived, the receiver would immediately generate a RESEND for the missing packets. Similarly, under certain circumstances, the receiver would generate a RESEND for a buffer N if packets for N were expected and had not arrived before packets for a buffer N+M. Obviously, packet- reordering made these "optimizations" generate retransmit requests unnecessarily. In the first case, the implementation was changed to no longer generate a retransmit request on receipt of an LDATA with other packets missing in the buffer. In the second case, a data timer was set with an updated (and presumably more accurate) value, hopefully allowing any re-ordered packets to arrive before timing out and generating a retransmit request.
Widebandネットワークに関する別の問題は、再注文する傾向と遅れパケットでした。 これらの問題に対処するのは実装における数回の変化を必要としました。 以前、NETBLT実装は生成する「最適化」ができるだけ早く要求を再送します、できれば、データタイマの満了に依存しないでことでした。 例えば、受信NETBLTがバッファNのためにLDATAパケットを受けて、バッファNの他のパケットがすぐに到着していなかったとき、受信機はなくなったパケットのためにRESENDを生成するでしょう。 同様に、ある状況で、Nのためのパケットが予想されて、バッファN+Mのためにパケットの前で到着していないなら、受信機はバッファNのためにRESENDを生成するでしょうに。 明らかに、パケット再命令で、「最適化」が生成するこれらは不必要に要求を再送しました。 前者の場合、実装を変えました。もうaを生成しないように、バッファでなくなった他のパケットがあるLDATAを受け取り次第要求を再送してください。 2番目の場合では、データタイマはアップデートされて(おそらくより正確)の値で設定されて、希望をいだいてどんな再命令されたパケットも以前到着するのを許容して、外で調節して、aを生成すると、要求は再送されます。
It is difficult to accommodate Wideband network packet delay in the NETBLT implementation. Packet delays tend to occur in multiples of 600 milliseconds, due to the Wideband network's datagram reservation scheme. A timer value calculation algorithm that used a fixed variance on the order of 600 milliseconds would cause performance degradation when packets were lost. On the other hand, short fixed variance values would not react well to the long delays possible on the Wideband net. Our solution has been to use an adaptive data timer value calculation algorithm. The algorithm maintains an average inter-packet arrival value, and uses that to determine the
NETBLT実装のWidebandネットワークパケット遅れを収容するのは難しいです。 パケット遅れは、Widebandネットワークのデータグラム予約体系のため、600ミリセカンドの倍数で起こる傾向があります。 パケットが失われたとき、600ミリセカンドの注文の固定変化を使用したタイマ値の計算アルゴリズムは性能退行を引き起こすでしょう。 他方では、短い固定変化の値はWidebandネットで可能な長時間の遅延によく反応しないでしょう。 私たちのソリューションは適応型のデータタイマ値の計算アルゴリズムを使用することです。 アルゴリズムは、決定するのに平均した相互パケット到着価値を維持して、それを使用します。
M. Lambert [Page 9] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[9ページ]RFC1030
data timer value. If the inter-packet arrival time increases, the data timer value will lengthen.
データタイマ価値。 相互パケット到着時間が増加すると、データタイマ価値は伸されるでしょう。
At this point, testing proceeded between NETBLT implementations on a SUN-3 workstation and an IBM PC/AT. The arrival of a Butterfly Gateway at ISI eliminated the need for source-routed packets; some performance improvement was also expected because the Butterfly Gateway is optimized for IP datagram traffic.
ここの、SUN-3ワークステーションとIBM PC/ATの上のNETBLT実装の間のテストしかけました。 ISIのButterflyゲートウェイの到着はソースによって発送されたパケットの必要性を排除しました。 また、ButterflyゲートウェイがIPデータグラムトラフィックのために最適化されるので、何らかの性能改良が予想されました。
In order to put the best Wideband network test results in context, a short analysis follows, showing the best throughput expected on a fully loaded channel. Again, a detailed analysis of the numbers that follow appears at the end of this document.
状況内において最も良いWidebandネットワーク試験の成績を置くために、短い分析は続きます、完全にロードされたチャンネルの上に予想される中で最も良い効率を示して。 一方、続く数の詳細に渡る分析はこのドキュメントの端に現れます。
The best possible datagram rate over the current Wideband configuration is 24,054 bits per channel frame, or 3006 bytes every 21.22 milliseconds. Since the transmission route begins and ends on an Ethernet, the largest amount of data transmissible (after accounting for packet header overhead) is 1438 bytes per packet. This translates to approximately 2 packets per frame. Since we want to avoid overflowing the channel, we should transmit slightly slower than the channel frame rate of 21.2 milliseconds. We therefore came up with a best possible throughput of 2 1438-byte packets every 22 milliseconds, or 1.05 megabits per second.
チャンネルフレームあたり現在のWideband構成での可能な限り良いデータグラムレートは2万4054ビットであるか3006バイトが21.22ミリセカンド毎です。 トランスミッションルートがイーサネットで始まって、終わるので、1パケットあたり伝えられるのである(パケットのヘッダーオーバーヘッドを説明した後の)最も大データ量は1438バイトです。 これは1フレームあたりおよそ2つのパケットに翻訳されます。 チャンネルからはみ出すのを避けたいと思うので、私たちは21.2ミリセカンドのチャンネルフレームレートよりわずかに遅く伝わるべきです。 したがって、私たちは22ミリセカンド毎、または1秒あたり1.05のメガビットに2つの1438年のバイトのパケットの可能な限り良い効率を思いつきました。
Because of possible software bugs in either the Butterfly Gateway or the BSAT (gateway-to-earth-station interface), 1438-byte packets were fragmented before transmission over the Wideband network, causing packet delay and poor performance. The best throughput was achieved with the following values:
ButterflyゲートウェイかBSATのどちらかの可能なソフトウェアのバグ(ゲートウェイから地上局へのインタフェース)のために、1438年のバイトのパケットはWidebandネットワークの上のトランスミッションの前に断片化されました、パケット遅れと不十分な性能を引き起こして。 最も良い効率は以下の値で達成されました:
transfer size 500,000 - 750,000 bytes
50万--75万バイトの転送サイズ
data packet size
1432 bytes
1432バイトのデータ・パケットサイズ
buffer size 14320 bytes
14320バイトのバッファサイズ
burst size 5 packets
放出量5パケット
burst interval 55 milliseconds
間隔を55ミリセカンドと同じくらい押し破いてください。
Steady-state throughputs ranged from 926 kilobits per second to 942 kilobits per second, approximately 90% channel utilization. The
定常状態スループットは2番目、およそ90%のチャンネル利用あたりのキロビットに1秒あたり926のキロビットから942まで及びました。 The
M. Lambert [Page 10] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[10ページ]RFC1030
amount of data transmitted should have been an order of magnitude higher, in order to get a longer steady-state period; unfortunately at the time we were testing, the Ethernet interface of ISI's Butterfly Gateway would lock up fairly quickly (in 40-60 seconds) at packet rates of approximately 90 per second, forcing a gateway reset. Transmissions therefore had to take less than this amount of time. This problem has reportedly been fixed since the tests were conducted.
伝えられたデータ量は、より長い定常状態の期間を得るために1桁より高かったはずです。 残念ながら当時、私たちはテストしていました、ゲートウェイが1秒あたりおよそ90のパケット速度でかなりすばやいこと(40-60秒以降)に鍵をかけるISIのButterflyのイーサネットインタフェース、ゲートウェイリセットを強制して。 したがって、トランスミッションはこの時間より取ってはいけませんでした。 伝えられるところによれば、テストが行われて以来、この問題は修正されています。
In order to test the Wideband network under overload conditions, we attempted several tests at rates of 5 1432-byte packets every 50 milliseconds. At this rate, the Wideband network ground to a halt as four of the ten network BSATs immediately crashed and reset their channel processor nodes. Apparently, the BSATs crash because the ESI (Earth Station Interface), which sends data from the BSAT to the satellite, stops its transmit clock to the BSAT if it runs out of buffer space. The BIO interface connecting BSAT and ESI does not tolerate this clock-stopping, and typically locks up, forcing the channel processor node to reset. A more sophisticated interface, allowing faster transmissions, is being installed in the near future.
過負荷条件の下でWidebandネットワークをテストするために、私たちは50ミリセカンド毎に5つの1432年のバイトのパケットのレートでいくつかのテストを試みました。 このままでいくと、10ネットワークBSATsのうち4がすぐに彼らのチャンネル・プロセッサノードを墜落して、リセットしたとき、Widebandネットワークはゆっくり止まりました。 ESI(地球駅のInterface)が止まるので明らかに、BSATsがダウンする、それ、バッファ領域を使い果たすなら、時計をBSATに送ってください。ESIはBSATから衛星にデータを送ります。 リセットへのチャンネル・プロセッサノードを強制して、BSATとESIを接続するのがこの時計停止、および通常錠を許容しないBIOインタフェース。 より速いトランスミッションを許容して、より洗練されたインタフェースは近い将来、インストールされる予定です。
8. Future Directions
8. 将来の方向
Some more testing needs to be performed over the Wideband Network in order to get a complete analysis of NETBLT's performance. Once the Butterfly Gateway Ethernet interface lockup problem described earlier has been fixed, we want to perform transmissions of 10 to 50 million bytes to get accurate steady-state throughput results. We also want to run several NETBLT processes in parallel, each tuned to take a fraction of the Wideband Network's available bandwidth. Hopefully, this will demonstrate whether or not burst synchronization across different NETBLT processes will cause network congestion or failure. Once the BIO BSAT-ESI interface is upgraded, we will want to try for higher throughputs, as well as greater hardware stability under overload conditions.
それ以上のテストが、NETBLTの性能の全分析を得るためにWideband Networkの上で実行される必要があります。 より早く説明されたButterflyゲートウェイイーサネットインタフェース留置所問題がいったん修正されると、正確な定常状態スループット結果を得るために10〜5000万バイトの送信を実行したいと思います。 また、いくつかのNETBLTプロセスを平行に実行したいと思います、Wideband Networkの利用可能な帯域幅の部分で取るために調整されたそれぞれ。 うまくいけば、異なったNETBLTプロセスの向こう側の炸裂同期がネットワークの混雑か失敗を引き起こすか否かに関係なく、これは示されるでしょう。 BIO BSAT-ESIインタフェースがいったんアップグレードすると、より高いスループットに挑戦したいと思うでしょう、過負荷条件の、よりすばらしいハードウェアの安定性と同様に。
As far as future directions of research into NETBLT, one important area needs to be explored. A series of algorithms need to be developed to allow dynamic selection and control of NETBLT's transmission parameters (burst size, burst interval, and number of outstanding buffers). Ideally, this dynamic control will not require any information from outside sources such as gateways; instead, NETBLT processes will use end-to-end information in order to make transmission rate decisions in the face of noisy channels and network congestion. Some research on dynamic rate control is taking place now, but much more work needs done before the results can be integrated into NETBLT.
NETBLTの研究の将来の方向と同じくらい遠くに、1つの重要な領域が、探検される必要があります。 一連のアルゴリズムが、NETBLTのトランスミッションパラメタ(傑出しているバッファの放出量、炸裂間隔、および数)のダイナミックな選択とコントロールを許すために開発される必要があります。 理想的に、この動的制御はゲートウェイなどの外部のソースからの少しの情報も必要としないでしょう。 代わりに、NETBLTプロセスは、騒がしいチャンネルとネットワークの混雑に直面して通信速度決定をするのに終わりから終わりへの情報を使用するでしょう。 ダイナミックな速度制御の何らかの研究が現在、行われていますが、結果をNETBLTと統合できる前に行われた必要性をはるかに扱ってください。
M. Lambert [Page 11] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[11ページ]RFC1030
I. Wideband Bandwidth Analysis
I. 広帯域帯域幅分析
Although the raw bandwidth of the Wideband Network is 3 megabits per second, currently only about 1 megabit per second of it is available to transmit data. The large amount of overhead is due to the channel control strategy (which uses a fixed-width control subframe based on the maximum number of stations sharing the channel) and the low- performance BIO interface between BBN's BSAT (Butterfly Satellite Interface) and Linkabit's ESI (Earth Station Interface). Higher- performance BSMI interfaces are soon to be installed in all Wideband sites, which should improve the amount of available bandwidth.
Wideband Networkの生の帯域幅は1秒あたり3つのメガビットですが、現在のそれの秒あたりおよそ1つのメガビットだけが、データを送るために利用可能です。 多量のオーバーヘッドがチャンネル対応戦略(チャンネルを共有するステーションの最大数に基づく固定幅調節「副-フレーム」を使用する)とBBNのBSAT(Butterfly Satellite Interface)とLinkabitのESI(地球駅のInterface)との低い性能BIOインタフェースのためです。 より高い性能BSMIインタフェースはすぐすべてのWidebandサイトにインストールされることになっています。(サイトは利用可能な帯域幅の量を改良するべきです)。
Bandwidth on the Wideband network is divided up into frames, each of which has multiple subframes. A frame is 32768 channel symbols, at 2 bits per symbol. One frame is available for transmission every 21.22 milliseconds, giving a raw bandwidth of 65536 bits / 21.22 ms, or 3.081 megabits per second.
Widebandネットワークにおける帯域幅はフレームに分割されます。それはそれぞれ複数の「副-フレーム」を持っています。 フレームは1シンボルあたり2ビットの32768のチャンネルシンボルです。 1個のフレームが21.22ミリセカンド毎にトランスミッションに利用可能です、65536ビット/21.22のms、または1秒あたり3.081のメガビットの生の帯域幅を与えて。
Each frame contains two subframes, a control subframe and a data subframe. The control subframe is subdivided into ten slots, one per earth station. Control information takes up 200 symbols per station. Because the communications interface between BSAT and ESI only runs at 2 megabits per second, there must be a padding interval of 1263 symbols between each slot of information, bringing the total control subframe size up to 1463 symbols x 10 stations, or 14630 symbols. The data subframe then has 18138 symbols available. The maximum datagram size is currently expressed as a 14-bit quantity, further dropping the maximum amount of data in a frame to 16384 symbols. After header information is taken into account, this value drops to 16,036 symbols. At 2 bits per symbol, using a 3/4 coding rate, the actual amount of usable data in a frame is 24,054 bits, or approximately 3006 bytes. Thus the theoretical usable bandwidth is 24,054 bits every 21.22 milliseconds, or 1.13 megabits per second. Since the NETBLT implementations are running on Ethernet LANs gatewayed to the Wideband network, the 3006 bytes per channel frame of usable bandwidth translates to two maximum-sized (1500 bytes) Ethernet packets per channel frame, or 1.045 megabits per second.
各フレームは2「副-フレーム」、コントロール「副-フレーム」、およびデータ「副-フレーム」を含んでいます。 コントロール「副-フレーム」は10のスロット、1地上局あたり1つに細分されます。 制御情報は1ステーションあたり200のシンボルを始めます。 BSATとESIとのコミュニケーションインタフェースが1秒あたり2つのメガビットで稼働するだけであるので、情報の各スロットの間には、1263のシンボルの詰め物間隔があるに違いありません、総コントロール「副-フレーム」サイズを1463のシンボルx10のステーション、または14630のシンボルまでもたらして。 そして、データ「副-フレーム」には、利用可能な18138のシンボルがあります。 最大のデータグラムサイズは現在14ビットの量として表されます、フレームでさらに最大のデータ量を16384のシンボルに下げて。 ヘッダー情報が考慮に入れられた後に、この値は1万6036のシンボルに落ちます。 1シンボルあたり2ビットでは、3/4コード化レートを使用して、フレームの実際の量の使用可能なデータが、2万4054ビット、またはおよそ3006バイトです。 したがって、理論上の使用可能な帯域幅は21.22ミリセカンド毎、または1秒あたり1.13のメガビットに2万4054ビットです。 NETBLT実装がWidebandネットワークにgatewayedされたイーサネットLANで動いているので、使用可能な帯域幅のチャンネルフレームあたり3006バイトはチャンネルフレームあたり(1500バイト)の2つの最大サイズのイーサネットパケット、または1秒あたり1.045のメガビットに翻訳されます。
M. Lambert [Page 12] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[12ページ]RFC1030
II. Detailed Proteon Ring LAN Test Results
II。 詳細なProteonリングLAN試験の成績
Following is a table of some of the test results gathered from testing NETBLT between two IBM PC/ATs on a Proteon Token Ring LAN. The table headers have the following definitions:
以下に、Proteon Token Ring LANの2IBM PC/ATsの間にテストNETBLTから集められた試験の成績のいくつかのテーブルがあります。 テーブルヘッダーには、以下の定義があります:
BS/BI burst size in packets and burst interval in
milliseconds
BS/BIはパケットでサイズを押し破いて、ミリセカンドで間隔を押し破きました。
PSZ number of bytes in DATA/LDATA packet data segment
DATA/LDATAパケットデータ・セグメントのPSZバイト数
BFSZ number of bytes in NETBLT buffer
NETBLTバッファのBFSZバイト数
XFSZ number of kilobytes in transfer
転送における、キロバイトのXFSZ番号
NBUFS number of outstanding buffers
傑出しているバッファのNBUFS番号
#LOSS number of data packets lost
#データ・パケットのLOSS番号は損をしました。
#RXM number of data packets retransmitted
#データ・パケットのRXM番号は再送されました。
DTMOS number of data timeouts on receiving end
犠牲者におけるデータタイムアウトのDTMOS番号
SPEED steady-state throughput in megabits per second
1秒あたりのメガビットにおけるSPEED定常状態スループット
M. Lambert [Page 13] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[13ページ]RFC1030
BS/BI PSZ BFSZ XFSZ NBUFS #LOSS #RXM DTMOS SPEED
両性愛者のBS/PSZ BFSZ XFSZ NBUFS#損失#RXM DTMOS速度
5/25 1438 14380 1438 1 0 0 0 1.45
5/25 1438 14380 1438 1 0 0 0 1.45
5/30 1438 14380 1438 1 0 0 0 1.45
5/30 1438 14380 1438 1 0 0 0 1.45
5/35 1438 14380 1438 1 0 0 0 1.40
5/35 1438 14380 1438 1 0 0 0 1.41
5/40 1438 14380 1438 1 0 0 0 1.33
5/40 1438 14380 1438 1 0 0 0 1.33
5/25 1438 14380 1438 1 0 0 0 1.45 5/25 1438 14380 1438 1 0 0 0 1.45 5/30 1438 14380 1438 1 0 0 0 1.45 5/30 1438 14380 1438 1 0 0 0 1.45 5/35 1438 14380 1438 1 0 0 0 1.40 5/35 1438 14380 1438 1 0 0 0 1.41 5/40 1438 14380 1438 1 0 0 0 1.33 5/40 1438 14380 1438 1 0 0 0 1.33
5/25 1438 14380 1438 2 0 0 0 1.62
5/25 1438 14380 1438 2 0 0 0 1.62
5/25 1438 14380 1438 2 0 0 0 1.61
5/30 1438 14380 1438 2 0 0 0 1.60
5/30 1438 14380 1438 2 0 0 0 1.61
5/34 1438 14380 1438 2 0 0 0 1.59
5/35 1438 14380 1438 2 0 0 0 1.58
5/25 1438 14380 1438 2 0 0 0 1.61 5/30 1438 14380 1438 2 0 0 0 1.60 5/30 1438 14380 1438 2 0 0 0 1.61 5/34 1438 14380 1438 2 0 0 0 1.59 5/35 1438 14380 1438 2 0 0 0 1.58
5/25 1990 19900 1990 1 0 0 0 1.48
5/25 1990 19900 1990 1 0 0 0 1.49
5/30 1990 19900 1990 1 0 0 0 1.48
5/30 1990 19900 1990 1 0 0 0 1.48
5/35 1990 19900 1990 1 0 0 0 1.49
5/35 1990 19900 1990 1 0 0 0 1.48
5/40 1990 19900 1990 1 0 0 0 1.49
5/40 1990 19900 1990 1 0 0 0 1.49
5/45 1990 19900 1990 1 0 0 0 1.45
5/45 1990 19900 1990 1 0 0 0 1.46
5/25 1990 19900 1990 1 0 0 0 1.48 5/25 1990 19900 1990 1 0 0 0 1.49 5/30 1990 19900 1990 1 0 0 0 1.48 5/30 1990 19900 1990 1 0 0 0 1.48 5/35 1990 19900 1990 1 0 0 0 1.49 5/35 1990 19900 1990 1 0 0 0 1.48 5/40 1990 19900 1990 1 0 0 0 1.49 5/40 1990 19900 1990 1 0 0 0 1.49 5/45 1990 19900 1990 1 0 0 0 1.45 5/45 1990 19900 1990 1 0 0 0 1.46
5/25 1990 19900 1990 2 0 0 0 1.75
5/25 1990 19900 1990 2 0 0 0 1.75
5/30 1990 19900 1990 2 0 0 0 1.74
5/30 1990 19900 1990 2 0 0 0 1.75
5/35 1990 19900 1990 2 0 0 0 1.74
5/35 1990 19900 1990 2 0 0 0 1.74
5/40 1990 19900 1990 2 0 0 0 1.75
5/40 1990 19900 1990 2 0 0 0 1.74
5/43 1990 19900 1990 2 0 0 0 1.75
5/43 1990 19900 1990 2 0 0 0 1.74
5/43 1990 19900 1990 2 0 0 0 1.75
5/44 1990 19900 1990 2 0 0 0 1.73
5/44 1990 19900 1990 2 0 0 0 1.72
5/45 1990 19900 1990 2 0 0 0 1.70
5/45 1990 19900 1990 2 0 0 0 1.72
5/25 1990 19900 1990 2 0 0 0 1.75 5/25 1990 19900 1990 2 0 0 0 1.75 5/30 1990 19900 1990 2 0 0 0 1.74 5/30 1990 19900 1990 2 0 0 0 1.75 5/35 1990 19900 1990 2 0 0 0 1.74 5/35 1990 19900 1990 2 0 0 0 1.74 5/40 1990 19900 1990 2 0 0 0 1.75 5/40 1990 19900 1990 2 0 0 0 1.74 5/43 1990 19900 1990 2 0 0 0 1.75 5/43 1990 19900 1990 2 0 0 0 1.74 5/43 1990 19900 1990 2 0 0 0 1.75 5/44 1990 19900 1990 2 0 0 0 1.73 5/44 1990 19900 1990 2 0 0 0 1.72 5/45 1990 19900 1990 2 0 0 0 1.70 5/45 1990 19900 1990 2 0 0 0 1.72
M. Lambert [Page 14] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[14ページ]RFC1030
III. Detailed Ethernet LAN Testing Results
III。 詳細なイーサネットLANテスト結果
Following is a table of some of the test results gathered from testing NETBLT between two IBM PC/ATs on an Ethernet LAN. See previous appendix for table header definitions.
以下に、イーサネットLANの2IBM PC/ATsの間にテストNETBLTから集められた試験の成績のいくつかのテーブルがあります。 テーブルヘッダー定義に関して前の付録を見てください。
BS/BI PSZ BFSZ XFSZ NBUFS #LOSS #RXM DTMOS SPEED
両性愛者のBS/PSZ BFSZ XFSZ NBUFS#損失#RXM DTMOS速度
5/30 1438 14380 1438 1 9 9 6 1.42
5/30 1438 14380 1438 1 2 2 2 1.45
5/30 1438 14380 1438 1 5 5 4 1.44
5/35 1438 14380 1438 1 7 7 7 1.38
5/35 1438 14380 1438 1 6 6 5 1.38
5/40 1438 14380 1438 1 48 48 44 1.15
5/40 1438 14380 1438 1 50 50 38 1.17
5/40 1438 14380 1438 1 13 13 11 1.28
5/40 1438 14380 1438 1 7 7 5 1.30
5/30 1438 14380 1438 1 9 9 6 1.42 5/30 1438 14380 1438 1 2 2 2 1.45 5/30 1438 14380 1438 1 5 5 4 1.44 5/35 1438 14380 1438 1 7 7 7 1.38 5/35 1438 14380 1438 1 6 6 5 1.38 5/40 1438 14380 1438 1 48 48 44 1.15 5/40 1438 14380 1438 1 50 50 38 1.17 5/40 1438 14380 1438 1 13 13 11 1.28 5/40 1438 14380 1438 1 7 7 5 1.30
5/30 1438 14380 1438 2 206 206 198 0.995
5/30 1438 14380 1438 2 213 213 198 0.994
5/40 1438 14380 1438 2 117 121 129 1.05
5/40 1438 14380 1438 2 178 181 166 0.892
5/40 1438 14380 1438 2 135 138 130 1.03
5/45 1438 14380 1438 2 57 57 52 1.12
5/45 1438 14380 1438 2 97 97 99 1.02
5/45 1438 14380 1438 2 62 62 51 1.09
5/30 1438 14380 1438 2 206 206 198 0.995 5/30 1438 14380 1438 2 213 213 198 0.994 5/40 1438 14380 1438 2 117 121 129 1.05 5/40 1438 14380 1438 2 178 181 166 0.892 5/40 1438 14380 1438 2 135 138 130 1.03 5/45 1438 14380 1438 2 57 57 52 1.12 5/45 1438 14380 1438 2 97 97 99 1.02 5/45 1438 14380 1438 2 62 62 51 1.09
5/15 512 10240 2048 1 6 6 4 0.909
5/15 512 10240 2048 1 10 11 7 0.907
5/18 512 10240 2048 1 11 11 8 0.891
5/18 512 10240 2048 1 5 5 9 0.906
5/19 512 10240 2048 1 3 3 3 0.905
5/19 512 10240 2048 1 8 8 7 0.898
5/20 512 10240 2048 1 7 7 4 0.876
5/20 512 10240 2048 1 11 12 5 0.871
5/20 512 10240 2048 1 8 9 5 0.874
5/30 512 10240 2048 2 113 116 84 0.599
5/30 512 10240 2048 2 20 20 14 0.661
5/30 512 10240 2048 2 49 50 40 0.638
5/15 512 10240 2048 1 6 6 4 0.909 5/15 512 10240 2048 1 10 11 7 0.907 5/18 512 10240 2048 1 11 11 8 0.891 5/18 512 10240 2048 1 5 5 9 0.906 5/19 512 10240 2048 1 3 3 3 0.905 5/19 512 10240 2048 1 8 8 7 0.898 5/20 512 10240 2048 1 7 7 4 0.876 5/20 512 10240 2048 1 11 12 5 0.871 5/20 512 10240 2048 1 8 9 5 0.874 5/30 512 10240 2048 2 113 116 84 0.599 5/30 512 10240 2048 2 20 20 14 0.661 5/30 512 10240 2048 2 49 50 40 0.638
M. Lambert [Page 15] RFC 1030 Testing the NETBLT Protocol November 1987
M。 NETBLTプロトコル1987年11月にテストするランバート[15ページ]RFC1030
IV. Detailed Wideband Network Testing Results
IV。 詳細な広帯域ネットワークテスト結果
Following is a table of some of the test results gathered from testing NETBLT between an IBM PC/AT and a SUN-3 using the Wideband satellite network. See previous appendix for table header definitions.
以下に、IBM PC/ATとSUN-3の間にテストNETBLTからWideband衛星ネットワークを使用することで集められた試験の成績のいくつかのテーブルがあります。 テーブルヘッダー定義に関して前の付録を見てください。
BS/BI PSZ BFSZ XFSZ NBUFS #LOSS #RXM SPEED
両性愛者のBS/PSZ BFSZ XFSZ NBUFS#損失#RXM速度
5/90 1400 14000 500 22 9 10 0.584
5/90 1400 14000 500 22 12 12 0.576
5/90 1400 14000 500 22 3 3 0.591
5/90 1420 14200 500 22 12 12 0.591
5/90 1420 14200 500 22 6 6 0.600
5/90 1430 14300 500 22 9 10 0.600
5/90 1430 14300 500 22 15 15 0.591
5/90 1430 14300 500 22 12 12 0.590
5/90 1432 14320 716 22 13 16 0.591
5/90 1434 14340 717 22 33 147 0.483
5/90 1436 14360 718 22 25 122 0.500
5/90 1436 14360 718 22 25 109 0.512
5/90 1436 14360 718 22 28 153 0.476
5/90 1438 14380 719 22 6 109 0.533
5/90 1400 14000 500 22 9 10 0.584 5/90 1400 14000 500 22 12 12 0.576 5/90 1400 14000 500 22 3 3 0.591 5/90 1420 14200 500 22 12 12 0.591 5/90 1420 14200 500 22 6 6 0.600 5/90 1430 14300 500 22 9 10 0.600 5/90 1430 14300 500 22 15 15 0.591 5/90 1430 14300 500 22 12 12 0.590 5/90 1432 14320 716 22 13 16 0.591 5/90 1434 14340 717 22 33 147 0.483 5/90 1436 14360 718 22 25 122 0.500 5/90 1436 14360 718 22 25 109 0.512 5/90 1436 14360 718 22 28 153 0.476 5/90 1438 14380 719 22 6 109 0.533
5/80 1432 14320 716 22 56 68 0.673
5/80 1432 14320 716 22 14 14 0.666
5/80 1432 14320 716 22 15 16 0.661
5/60 1432 14320 716 22 19 22 0.856
5/60 1432 14320 716 22 84 95 0.699
5/60 1432 14320 716 22 18 21 0.871
5/60 1432 14320 716 30 38 40 0.837
5/60 1432 14320 716 30 25 26 0.869
5/55 1432 14320 716 22 13 13 0.935
5/55 1432 14320 716 22 25 25 0.926
5/55 1432 14320 716 22 25 25 0.926
5/55 1432 14320 716 22 20 20 0.932
5/55 1432 14320 716 22 17 19 0.934
5/55 1432 14320 716 22 13 14 0.942
5/80 1432 14320 716 22 56 68 0.673 5/80 1432 14320 716 22 14 14 0.666 5/80 1432 14320 716 22 15 16 0.661 5/60 1432 14320 716 22 19 22 0.856 5/60 1432 14320 716 22 84 95 0.699 5/60 1432 14320 716 22 18 21 0.871 5/60 1432 14320 716 30 38 40 0.837 5/60 1432 14320 716 30 25 26 0.869 5/55 1432 14320 716 22 13 13 0.935 5/55 1432 14320 716 22 25 25 0.926 5/55 1432 14320 716 22 25 25 0.926 5/55 1432 14320 716 22 20 20 0.932 5/55 1432 14320 716 22 17 19 0.934 5/55 1432 14320 716 22 13 14 0.942
M. Lambert [Page 16]
M。 ランバート[16ページ]
一覧
スポンサーリンク
