RFC557 日本語訳

0557 REVELATIONS IN NETWORK HOST MEASUREMENTS. B.D. Wessler. August 1973. (Format: TXT=3167, PDF=90256 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                         B. Wessler
Request for Comments: 557                         Telenet Communications
NIC: 18457                                                30 August 1973
References: RFC 392, 415

Wesslerがコメントのために要求するワーキンググループB.をネットワークでつないでください: 557テレネットコミュニケーションNIC: 18457 1973年8月30日の参照: RFC392、415

                REVELATIONS IN NETWORK HOST MEASUREMENTS

ネットワークホスト測定値における示現

   The purpose of RFC 392 was to identify a problem we had encountered
   in using the ARPANET at Utah.  The primary thrust of the paper was
   supposed to be: "Here is a place to make the Network better" rather
   than: "Look, isn't the Network terrible."  The accepted use of 392
   seems to be the latter rather than the former.  A second purpose of
   392 was to stimulate the undertaking of measurement experiments on
   other computers and operating systems in addition to TENEX.  Very
   little in the way of measurements has been reported (other than Hal
   Murray's RFC 415 measuring TENEX).

RFC392の目的は私たちがユタでアルパネットを使用する際に行きあたった問題を特定することでした。 紙の第一の突きは以下の通りであるべきでした。 以下のというよりむしろ、「ここに、Networkをより良くする場所があります」。 「ほら、Networkはひどくはありません」? 392の受け入れられた使用は前者よりむしろ後者であるように思えます。 392の2番目の目的はTENEXに加えた他のコンピュータとオペレーティングシステムにおける測定実験の仕事を刺激することでした。 測定値の方法でほとんど、報告されていません(ハル・マレーのRFC415測定TENEX以外に)。

   Since the Publication of RFC 392, BBN has done a considerable amount
   of work to improve Host-Net performance on TENEX.  They reported new
   measurement results in their April 1973 Quarterly Progress Report No.
   10.  I feel it is important to circulate those results to the RFC
   community.

RFC392のPublication以来、BBNは、TENEXに関するHost-ネット性能を向上させるためにかなりの量の仕事をしています。 彼らは自分達の1973年4月のQuarterly Progress Report No.10で新しい測定結果を報告しました。 私は、RFC共同体にそれらの結果を循環させるのが重要であると感じます。

   Don Allen at BBN borrowed Greg Hicks' RJS program and 1) updated it
   to take advantage of recent changes in TENEX, 2) improved the code
   near the input/output JSYs and 3) used considerably faster network
   monitor code.  The result was approximately 400% improvement from
   75-85 seconds of CPU time per megabit (~$10) to 19 seconds per
   megabit (~$2.50).  Of the 19 seconds, 13 were spent in the RJS
   program and 6 in TENEX network output.  The six seconds seem to
   relate very well to BBN FTP requirements where 8.2 cpu seconds per
   megabit were required (~$1.08) for 8 bit byte transfers.  (Going to
   32 or 36 bit bytes improves this figure by a factor of 4, resulting
   in a cost of $.33 per megabit.)

BBNのドン・アレンはグレッグ・ヒックスのRJSプログラムを借りました、そして、1は)TENEXにおける最近の変化を利用するためにそれをアップデートしました、そして、2は)入力/出力JSYsの近くでコードを改良しました、そして、3は)かなり速いネットワークモニターコードを使用しました。 結果は75-85メガビット(~2.50ドル)あたり19秒までのメガビット(~10ドル)あたりの秒のCPU時間からのおよそ400%の改良でした。 19秒では、13はTENEXネットワーク出力でRJSプログラムと6に費やされました。 6秒は、1メガビットあたり8.2cpu秒が8ビットのバイトに必要であったところで(~1.08ドル)BBN FTP要件に非常によく関連するのが移されるように思えます。 (32ビットか36ビットのバイトまで行くのは4の要素でこの図を改良します、1メガビットあたり.33ドルの費用をもたらして。)

   Of the 13 seconds left in RJS no attempt was made to improve or even
   discover where the time was spent.  This extra effort was not
   expended because RJS is soon to be replaced by the RJE protocol which
   uses FTP as its transfer mechanism.

RJSに残っている13秒では、向上するか、または時間がどこで費やされるかを発見するのさえ試みを全くしませんでした。 すぐRJSがトランスファ・メカニズムとしてFTPを使用するRJEプロトコルに取り替えられることになっているので、この余分な努力は費やされませんでした。

   In summary, I believe that the original RFC #392 and the recent BBN
   results show that the Network including the Host cost, is
   intrinsically effective.  If care is not taken in monitor and user
   code the system may not look very attractive.  I hope everyone now
   goes out and measures how good (or bad) they are doing vis a vis

概要を、私は、オリジナルのRFC#392、と最近のBBN結果が、Host費用を含むNetworkが本質的に有効であることを示すと信じています。 モニターとユーザコードで注意しないなら、システムは非常に魅力的に見えないかもしれません。 皆が、今、出かけて、visにvisをして、それらがどれくらい良い、そして、(悪い)であるかと測定することを願っています。

Wessler                                                         [Page 1]

RFC 557         REVELATIONS IN NETWORK HOST MEASUREMENTS     August 1973

ネットワークホスト測定値1973年8月のWessler[1ページ]RFC557示現

   network transfers.  Please send me the results personally if they are
   too embarrassing to distribute via RFC.  It would be nice to hear
   from all systems.

転送をネットワークでつないでください。 それらがRFCを通して分配できないくらい恥ずかしいなら、個人的に結果を私に送ってください。 すべてのシステムから聞いてうれしいでしょう。

   All the data is courtesy of Don Allen and Jerry Burchfiel at BNN.

すべてのデータがドン・アレンとジェリーBurchfielの提供でBNNにあります。

         [ This RFC was put into machine readable form for entry ]
             [ into the online RFC archives by Lorrie Shiota ]

[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ロリー塩田によるオンラインRFCアーカイブへの]

Wessler                                                         [Page 2]

Wessler[2ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

ssh-keygen SSH用の公開かぎ,秘密かぎのペアを作成する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る