RFC392 日本語訳
0392 Measurement of host costs for transmitting network data. G.Hicks, B.D. Wessler. September 1972. (Format: TXT=14462 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Hicks Request for Comments: 392 B. Wessler NIC: 11584 Utah 20 September 1972
田舎者がコメントのために要求するワーキンググループG.をネットワークでつないでください: 392 B.Wessler NIC: 11584 ユタ1972年9月20日
Measurement of Host Costs for Transmitting Network Data
ネットワークデータを送るためのホストコストの測定
Background for the UTAH Timing Experiments
ユタタイミング実験のためのバックグラウンド
Since October 1971 we, at the University of Utah, have had very large compute bound jobs running daily. These jobs would run for many cpu hours to achieve partial results and used resources that may be better obtained elsewhere. We felt that since these processes were being treated as batch jobs, they should be run on a batch machine.
10月以来、私たちがユタ大学で非常に大きくした1971は毎日走る制限された仕事を計算します。 これらの仕事は、部分的な結果とほかの場所で得られるほうがよい中古のリソースを獲得するためにcpu何時間も立候補するでしょう。 私たちは、これらの過程がバッチ・ジョブとして扱ったことにされるのであるのでそれらがバッチマシンの上を走るべきであると感じました。
To meet the needs of these "batch" users, in March of this year, we developed a program[1] to use the Remote Job Service System (RJS) at UCLA-CCN. RJS at UCLA is run on an IBM 360/91.
今年の3月のこれらの「バッチ」ユーザの需要を満たすなら、私たちは、UCLA-CCNでRemote Job Service System(RJS)を使用するためにプログラム[1]を開発しました。 UCLAのRJSはIBM360/91を走ります。
Some examples of these jobs were (and still are!):
これらの仕事に関するいくつかの例はこと(そして、まだ、あります!)でした:
(a) Algebraic simplification (using LISP and REDUCE)
(a) 代数的な簡素化(使用して、舌たらずに話してください、そして、減少してください)
(b) Applications of partial differential equation solving
(b) 偏微分方程式解決のアプリケーション
(c) Waveform processing (both audio and video)
(c) 波形の処理(オーディオとビデオの両方)
The characteristics of the jobs run on the 91 were small data decks being submitted to RJS and massive print files being retrieved. With one exception: The waveform processing group needed, from time to time, to store large data files at UCLA for later processing. When this group did their processing, they retrieved very large punch files that were later displayed or listened to here.
91における仕事の走行の特性は、RJSに提出される小さいデータデッキと取られる大規模な印刷ファイルでした。 ただ1つを例外として: 波形の処理グループは、時々後で処理するために大きいデータファイルをUCLAに格納する必要がありました。 このグループが彼らの処理をしたとき、彼らはここで後で表示したか、または聞いた非常に大きいパンチファイルを取りました。
When the program became operational in late march -- and started being used as a matter of course -- users complained that the program page faulted frequently. We restructured the program so that the parts that were often used did not cross page boundaries.
プログラムは当然のこととして使用される操作上のコネ遅い行進、および始められた存在になりました--プログラムページが頻繁にとがめた不平を言われたユーザのときに 私たちは、しばしば使用された部品がページ・バウンダリに交差しなかったように、プログラムを再構築しました。
The protocol with RJS at UCLA requires that all programs and data to be transmitted on the data connection be blocked[2]. This means that we simulate records and blocks with special headers. This we found to be another problem because of the computation and core space involved. This computation took an appreciable amount of time and core space we found because of our real core size that we were being charged an excessive amount due to page faulting. The page faulting also reduced our real-time transmission rate to the extent that we
RJSがUCLAにあるプロトコルは、すべてのデータ接続のときに伝えられるべきプログラムとデータが妨げられるのを必要とします。[2]。 これは、私たちが特別なヘッダーをもって記録とブロックをシミュレートすることを意味します。 私たちがスペースがかかわった計算とコアによる別の問題になるように見つけたこれ。 この計算はページのとがめのため私たちが請求されていた本当のコアサイズのために過量を見つけたかなりの時間とコアスペースがかかりました。 また、ページのとがめが私たちのリアルタイムの通信速度を範囲まで減少させた、それ、私たち
Hicks & Wessler [Page 1] RFC 392 Measurement for Transmitting Network Data September 1972
ネットワークデータ1972年9月に伝わるためのヒックスとWessler[1ページ]RFC392測定
felt a re-write of the transmitting and receiving portions of the program was needed. In order that the program receive the best service from the system, these portions optimized so that they each occupied a little over half of a page. As we now had so few pages in core at any one time, the TENEX scheduler could give the program preference over larger working set jobs. (As an aside, because of our limited core, we have written a small (one and one half pages) editor in order to provide an interactive text editing service.)
プログラムの伝えるのと受信一部の書き直しが必要であったと感じました。 プログラムがシステムから最も良いサービスを受けるようにこれらの部分が最適化されたので、それらはそれぞれ半分の1ページを占領しました。 私たちがいかなる時も今やコアにとても数ページしか持っていなかったので、TENEXスケジューラは、より大きいワーキングセット仕事の上にプログラム優先を与えるかもしれません。 (余談として、限られたコアのために、私たちは対話的なテキスト編集サービスを提供するために(1.5ページ)の小さいエディタに書きました。)
The mechanism to access the network under TENEX is file oriented. This means byte-in (BIN) and byte-out (BOUT) must be used to communicate with another host. The basic timing of these two instructions (in the fast mode) is 120 us per byte to get the data onto or off of the network[3]. A distinction was made because the TENEX monitor must do some "bit shuffling" to ready the users bytes to be transmitted or it must put the network messages into some form that is convenient for the user. This is the "slow bin, bout" and occurs once per message. If the users bytes are 36 bits long then it will take an average of 500 us per message. If the bytes have to be unpacked from the message to be usable, then it may take up to a milli-second depending on the size of the message[3].
TENEXの下でネットワークにアクセスするメカニズムはファイル指向しています。 これは、別のホストとコミュニケートするのに中のバイト(BIN)と外のバイト(BOUT)を使用しなければならないことを意味します。 これらの2つの指示(速いモードによる)の基本的なタイミングはそうです。120 ネットワークかネットワーク[3]からデータを得るバイトあたりの私たち。 TENEXモニターが伝えられるためにいくつかの「噛み付いているシャッフル」に準備ができていることへのユーザバイトをしなければならないので、区別をしたか、またはそれはユーザが都合がよい何らかのフォームにネットワークメッセージを入れなければなりません。 これは、「遅い容器、一続き」であり、1メッセージに一度起こります。 ユーザバイトが長さ36ビットであるなら、それはメッセージ単位で撮影平均500に私たちを望んでいます。 バイトが使用可能になるメッセージからアンパックされなければならないなら、それはメッセージ[3]のサイズに依存する最大1人のミリセカンドと同じくらい取るかもしれません。
II. Measurements and Results
II。 測定値と結果
We found by timing various portions of the program that the RJS program was using 600 to 700 us per bit byte or between 75 and 85 micro-seconds of chargeable cpu time per bit. (See tables 1 and 2 for actual results). A short discussion of how these figures were obtained is now in order. NOTE! We have not been trying to measure network transmission rates; Rather, how much it costs us to take a program (data) from our disk and send it to another host to be executed (processed).
私たちは、タイミングでRJSがプログラムするプログラムの様々な部分が1ビット単位で私たちを請求できるcpu timeの1ビットあたりバイトか75〜85マイクロセカンド600〜700に使用していたのがわかりました。 (実際の結果に関してテーブル1と2を見ます。) どうこれらの数字を得たかに関する短い議論は現在、整然としています。 注意してください! 私たちはネットワーク通信速度を測定しようとしていませんでした。 むしろ、いくらが私たちをそれに費やすかが、私たちのディスクからプログラム(データ)を取って、実行される(処理される)ために別のホストにそれを送ります。
Column 1 is the clock time (real-time) from when the first byte was brought in from the disk until the last byte had gone onto the network. (Or from the time we received the first byte from the network until the disk file was closed).
コラム1は最後のバイトがネットワークに行くまで最初のバイトがディスクから持って入られた時からのクロック・タイム(リアルタイムの)です。 (時間から、ディスクファイルが閉じられるまで、私たちはネットワークから最初のバイトを受けました。)
Column 2 is computed in the same manner as column 1 except that it is the chargeable runtime for the process.
それが過程のための請求できるランタイムであるのを除いて、コラム2はコラム1と同じ方法で計算されます。
Column 3 is the actual number of bytes that went onto or came from the network. The letter that follows this column indicates the direction. E.G. s for sending to UCLA, r for receiving from UCLA).
コラム3はネットワークから行ったか、または来た実際のバイト数です。 このコラムに従う手紙は指示を示します。 UCLAに発信するためのE.G.s、UCLAから受信するためのr)
Column 4 was calculated by the following formula: Bits per second = (real-time)/((number of bytes)*8)
コラム4は以下の公式によって計算されました: bpsは(リアルタイムで)の/と等しいです。((バイト数)*8)
Hicks & Wessler [Page 2] RFC 392 Measurement for Transmitting Network Data September 1972
ネットワークデータ1972年9月に伝わるためのヒックスとWessler[2ページ]RFC392測定
Column 5 was calculated by the formula: us/bit = (chargeable runtime)*1000/((number of bytes)*8)
コラム5は公式によって計算されました: 私たち、/ビット=(請求できるランタイム)*1000/((バイト数)*8)
Column 6 is the 5 minute load average. (See TENEX documentation for details.)
コラム6は5分間負荷平均です。 (詳細に関してTENEXドキュメンテーションを見てください。)
Using these figures we can conclude that for a million bits of information -- programs to be executed or data -- it would take 75 to 85 cpu seconds to transmit. At a cost of $474.60 per cpu hour on TENEX's[5], this millionbits would cost $9.90 to 11.20 to transfer from the originating host and potentially the same for the foreign host to receive. This is about 33 to 37 times higher than the predicted network transmission costs[4].
これらの数字を使用して、私たちは、伝わるように100万ビットの情報(実行されるべきプログラムかデータ)には、それが75〜85cpu秒かかると結論を下すことができます。 TENEXの[5]のcpu毎時の474.60ドルの費用では、このmillionbitsは、異種宿主が受信するように送信元ホストと潜在的に同じくらいから移動するのに9.90〜11.20ドルかかるでしょう。 これは、予測されたネットワーク送信が[4]かかるより何倍も高くおよそ33〜37です。
It is to be noticed that, in some cases, for programs to be transmitted over the network, the cost incurred by transmitting them was greater than the cost of executing these programs at the foreign host!
プログラムがネットワークの上に放送されるために、いくつかの場合でそれらを伝えることによって被られた費用が異種宿主でこれらのプログラムを実行する費用より大きかったのに気付かれることになっています!
III. Analysis
III。 分析
There may be numerous ways to reduce the cost of the network to the host:
ネットワークのコストをホストに削減する多数の方法があるかもしれません:
(a) Treat the network not as a file device but as an interprocess communications device[6].
(a) ファイル装置として扱うのではなく、プロセス間通信装置[6]としてネットワークを扱ってください。
(b) Create an 'intelligent' network input/output device. This would, of course, be customized for individual types of operating systems and hardware configurations. For TENEX systems this could be implemented as the ability to do mapping operations from the users virtual memory 'directly' onto the network. In any case, this intelligent network device would be required to handle the various protocols for the host. Some changes may be required in the NCP protocols.
(b) '知的な'ネットワーク入力/出力装置を作成してください。 これは独特のタイプのオペレーティングシステムとハードウェア・コンフィギュレーションのためにもちろんカスタム設計されるでしょう。 TENEXシステムにおいて、操作をユーザ仮想記憶から'直接'ネットワークに写像しながら、する能力としてこれを実行できました。 どのような場合でも、このインテリジェントネットワーク装置が、ホストのために様々なプロトコルを扱うのに必要でしょう。 いくつかの変化がNCPプロトコルで必要であるかもしれません。
A way to reduce the cost of the RJS program (the one measured in tables 1 and 2) would be to change the RJS-UCLA protocol. One possible change is to allow hosts the option of using 32 bit bytes (because it may be more efficient!) instead of the 8 bit bytes now required by the protocol.
RJSプログラム(テーブル1と2で測定されたもの)のコストを削減する方法はRJS-UCLAプロトコルを変えるだろうことです。 1回の可能な変化が現在8ビットのバイトの代わりに32ビットのバイトを使用する(それが、より効率的であるかもしれないので!)オプションがプロトコルで必要としたホストを許容することになっています。
Basically, it is our belief, that, in order to make the network as viable economically as was anticipated by the authors of reference[4], much work is needed on host machines and network protocols rather than on further refinements of the communication devices involved.
基本的に、それは多くの仕事が参照[4]の作者によって予期されたように実行可能であるとしてネットワークを経済的に作るのにホスト・マシンとかかわった通信装置のさらなる気品に関してというよりむしろネットワーク・プロトコルで必要であるという私たちの信念です。
Hicks & Wessler [Page 3] RFC 392 Measurement for Transmitting Network Data September 1972
ネットワークデータ1972年9月に伝わるためのヒックスとWessler[3ページ]RFC392測定
References
参照
1. Hicks, Gregory, "Network Remote Job Entry Program--NETRJS", Network Information Center #9632, RFC #325
1. ヒックス、グレゴリー、「リモートジョブエントリプログラムをネットワークでつないでください--NETRJS」、情報センター#9632、RFC#325をネットワークでつないでください。
2. Braden, R.T., "Interim NETRJS Specifications", Network Information Center #7133, RFC #189, July 5,1971
2. ブレーデン、R.T.、「当座のNETRJS仕様」が情報センター#7133、RFC#189、1971年7月5日をネットワークでつなぎます。
3. Personal correspondence with R. S. Tomlinson of Bolt, Beranek & Newman during the time period of 13-SEPT-71 to 19-SEPT-72.
3. 期間の19 9月の72への13 9月71歳のBoltのR.S.トムリンスン、Beranek、およびニューマンとの個人的な通信。
4. Roberts, L.G., and B.D. Wessler, "Computer Network Development to achieve resource sharing", Spring Joint Computer Conference, May 7,1970 pg 543-549.
4. ロバーツ、L.G.とB.D.Wessler、「リソース・シェアリングを達成するコンピュータNetwork Development」春季計算機学会合同会議、1970年5月7日pg543-549。
5. Personal correspondence with Bolt, Beranek & Newman
5. Bolt、Beranek、およびニューマンとの個人的な通信
6. Bressler, B., D. Murphy and D. Walden, "A proposed Experiment with a Message Switching Protocol", Network Information Center #9926, RFC #333, May 15,1972.
6. BresslerとB.とD.マーフィーとD.ウォルデン、「Message Switchingプロトコルがある提案されたExperiment」、Networkインフォメーション・センター#9926、RFC#333、1972年5月15日。
Hicks & Wessler [Page 4] RFC 392 Measurement for Transmitting Network Data September 1972
ネットワークデータ1972年9月に伝わるためのヒックスとWessler[4ページ]RFC392測定
Utah-10 Accounting for Network Usage
ネットワーク用法のためのユタ-10会計
for the period 16-SEP-72 12:48:34, ending 19-SEP-72 13:56:11
期間16 9月の72 12: 48:34、終わりの19 9月の72 13のために:、56:11
Clk Tim Cpu Tim # of Bytes Bits/sec us/bit Load
Bytes Bits/秒のClkティム・Cpuティム#、私たち、/ビットLoad
14 11.61 18930 s 10152.175 76.67 3.74 02:56 37.89 59066 r 2670.857 80.20 3.51 02:18 22.71 35377 r 2038.682 80.24 2.98 01:31 34.37 56608 s 4966.431 75.89 3.35 13 11.57 19094 s 10985.401 75.72 4.07 04:03 42.03 63067 r 2069.297 83.30 4.95 03 1.82 2906 s 5932.126 78.37 5.58 45 23.58 35505 r 6237.976 83.00 5.37 09 2.08 3243 s 2804.757 80.21 3.60 03:28 39.25 58632 r 2246.727 83.69 4.86 05 4.60 7470 s 10192.734 76.99 1.12 23 10.83 16525 r 5565.378 81.95 1.17 06 4.32 7142 s 9116.962 75.64 1.44 14 8.56 13223 r 7170.338 80.95 1.29 11 4.42 7142 s 4795.300 77.43 1.89 01:34 13.287 19562 r 1659.819 84.86 2.50 37 10.35 16183 r 3439.807 79.97 3.02 02:43 34.49 56444 s 2764.170 76.38 3.74 38 10.51 16196 r 3400.467 81.13 0.69 45 34.12 56280 s 9820.704 75.75 2.57 03:46 36.09 56280 s 1990.601 80.16 4.06 11 2.75 4085 r 2774.900 84.30 4.86 15 2.88 4085 r 2154.252 88.07 4.86 01:54 11.40 16125 r 1124.203 88.39 5.12 01:14 35.10 56280 s 6057.068 77.96 6.10 01:07 10.67 16125 r 1919.986 82.70 1.89 04:28 36.32 56362 s 1679.377 80.56 5.52 02:12 17.71 27120 r 1634.818 81.62 1.73 06:59 41.88 64333 s 1226.980 81.37 6.66 37 7.63 12082 r 2552.243 78.97 0.64
18930秒間の14 11.61、10152.175 76.67 3.74 02、: 56 37.89 59066、r、2670.857 80.20 3.51 02、: 18 22.71 35377、r、2038.682 80.24 2.98 01、: 31 34.37、56608秒間4966.431 75.89 3.35 13 11.5719094秒間、10985.401 75.72 4.07 04、: 03 42.03 63067、3243秒間のr2069.297 83.30 4.95 03 1.822906秒間5932.126 78.37 5.58 45 23.58 35505r6237.976 83.00 5.37 09 2.08、2804.757 80.21 3.60 03、: 28 39.25 58632、r2246.727 83.69 4.86 05 4.607470秒間10192.734 76.99 1.12 23 10.83 16525r5565.378 81.95 1.17 06 4.327142秒間9116.962 75.64 1.44 14 8.56 13223r7170; 7142秒間..56444秒間..56280秒間..56280秒間..56280秒間..56362秒間2 02:12 17.71 27120r1634.818 81.62 1.73 06: 59 41.8864333秒間1226.980 81.37 6.66 37 7.63 12082r2552.243 78.97 0.64
Utah-10 Accounting for Network Usage
ネットワーク用法のためのユタ-10会計
for the period 13-SEP-72 2:23:12, ending 16-SEP-72 11:47:07
期間13 9月の72の2:23:12、終わりの16 9月の72 11のために:、47:07
Clk Tim Cpu Tim # of Bytes Bits/sec us/bit Load
Bytes Bits/秒のClkティム・Cpuティム#、私たち、/ビットLoad
10 2.09 3079 s 2343.227 84.77 3.80 11:09 138.20 204596 s 2444.733 84.43 3.68 06:16 34.78 49994 r 1062.961 86.96 3.95 01:57 16.25 24971 r 1693.451 81.34 2.92 12:07 114.70 183598 s 2019.577 78.09 6.79
10 2.09 3079秒間2343.227 84.77 3.80 11(09 138.20 204596秒間2444.733 84.43 3.68 06(16 34.78 49994 r1062.961 86.96 3.95 01: 57 16.25 24971 r1693.451 81.34 2.92 12:、))07 114.70、183598秒間2019.577 78.09 6.79
Hicks & Wessler [Page 5] RFC 392 Measurement for Transmitting Network Data September 1972
ネットワークデータ1972年9月に伝わるためのヒックスとWessler[5ページ]RFC392測定
01:13 0.92 845 r 91.683 135.80 2.12 05 5.07 7373 s 10842.647 85.99 1.93 03:09 42.10 62414 r 2633.655 84.31 3.86 13:22 115.13 183352 s 1828.467 78.49 0.58 02 0.25 233 s 907.056 134.12 6.05 07:10 44.23 64869 r 1206.001 85.23 5.07 04 0.33 233 s 402.679 179.18 2.24 11:47 114.48 183585 s 2076.187 77.95 2.73 17:45 128.25 185908 r 1395.801 86.23 5.19 09:34 45.97 67158 r 935.067 85.56 0.61 09:23 113.50 183270 s 2600.852 77.41 9.64 12:24 51.65 74916 r 804.656 86.18 9.28 13:30 117.92 183352 s 1809.320 80.39 9.08 19:23 56.42 89640 s 616.586 78.67 6.77 11:49 11.29 16205 r 182.767 87.08 10.17 09:05 34.35 50796 s 744.325 84.53 8.47 21:12 56.17 76423 r 480.512 91.88 7.53 01:00 15.33 23930 r 3156.628 80.08 3.11 03:04 54.60 89731 s 3892.062 76.07 3.81 06 2.62 4106 r 5071.484 79.88 3.77 05:15 54.79 89731 s 2277.559 76.32 3.68 03 2.02 3161 s 7778.530 79.92 2.17 33 9.42 14680 r 3472.810 80.19 2.31 00 0.22 219 s 2646.526 127.28 1.81 19:57 295.16 473489 s 3162.399 77.92 1.85 10 6.62 10025 r 7841.987 82.54 2.75 01 0.23 221 s 1092.032 128.96 2.74 16 6.45 10032 r 1888.591 80.36 2.79 04 2.06 3243 s 6020.887 79.52 2.62 01:28 31.29 48532 r 4382.419 80.60 2.62 07:17 196.34 316072 s 5777.687 77.65 3.86 01:46 30.14 45786 r 3434.229 82.29 3.26 01:30 24.73 38405 r 3399.274 80.50 1.80 02:10 23.46 35633 r 2190.508 82.31 2.61 44 28.80 46897 s 8441.544 76.76 3.26 04:51 192.20 316318 s 8671.027 75.95 3.10 40 11.51 18511 s 3633.437 77.70 2.98 12 7.17 10963 r 6894.427 81.76 3.04 12 11.30 18511 s 11418.614 76.32 3.14 14 7.12 11122 r 6298.740 80.03 3.24 02 0.92 1412 s 5120.580 81.53 3.41 14 7.23 11122 r 6184.042 81.24 3.20
7373秒間..183352秒間..233秒間..233秒間..183585秒間..183270秒間..183352秒間; 08 19: 23 56.42 89640秒間、616.586 78.67 6.77 11、: 49 11.29 16205、r、182.767 87.08 10.17 09、: 05 34.35、50796秒間、744.325 84.53 8.47 21、: 12 56.17 76423、r、480.512 91.88 7.53 01、: 00 15.33 23930、r、3156.628 80.08 3.11 03、: 04 54.60、89731秒間3892.062 76.07 3.81 06 2.62 4106r5071; 484 79.88 3.77 05: 219秒間の15 54.7989731秒間2277.559 76.32 3.68 03 2.023161秒間7778.530 79.92 2.17 33 9.42 14680r3472.810 80.19 2.31 00 0.22、2646.526 127.28 1.81 19、: 221秒間の57 295.16473489秒間3162.399 77.92 1.85 10 6.62 10025r7841.987 82.54 2.75 01 0.23、103243秒間の92.032 128.96 2.74 16 6.45 10032r1888.591 80.36 2.79 04 2.06、6020.887 79.52 2.62 01、: 28 31.29 48532、r、4382.419 80.60 2.62 07、: 17 196.34、316072秒間、5777.687 77.65 3.86 01、: 46 30.14 45786、r、3434.229 82.29 3.26 01、: 30 24.73 38405、r、3399.274 80.50 1.80 02、: 10 23.46 35633、r2190.508 82.31 2.61 44 28; 80 46897秒間8441.544 76.76 3.26 04(1412秒間の51 192.20316318秒間8671.027 75.95 3.10 40 11.5118511秒間3633.437 77.70 2.98 12 7.17 10963r6894.427 81.76 3.04 12 11.3018511秒間11418.614 76.32 3.14 14 7.12 11122r6298.740 80.03 3.24 02 0.92、)5120.580 81.53 3.41 14 7.23 11122r6184.042 81.24 3.20
[This RFC was put into machine readable form for entry] [into the online RFC archives by Helene Morin, Viagenie, 12/99]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ヘレーネのモーリン、ViagenieによるオンラインRFCアーカイブへの12/99]
Hicks & Wessler [Page 6]
ヒックスとWessler[6ページ]
一覧
スポンサーリンク