RFC573 日本語訳
0573 DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS. A. Bhushan. September 1973. (Format: TXT=19474, PDF=543794 bytes) (Status: UNKNOWN)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Bhushan Request for Comments: 573 MIT-DM NIC: 19083 14 September 1973
Bhushanがコメントのために要求するワーキンググループA.をネットワークでつないでください: 573MIT-DM NIC: 19083 1973年9月14日
DATA AND FILE TRANSFER - SOME MEASUREMENT RESULTS
データとファイル転送--いくつかの測定結果
During the last six months, we have been monitoring (although not continuously) the performance of our FTP-user and FTP-server programs. The purpose of this paper is to 1) discuss measurement criteria, 2) describe the measurement facilities, 3) report the relevant measurement results, 4) discuss the significance of results and compare them with other measurement data, and 5) ask for suggestions on our measurement and summarizing procedures.
ここ6カ月、私たちは私たちのFTPユーザとFTPサーバプログラムの性能をモニターしています(絶え間なくはありませんが)。この紙の目的は1まで、)測定評価基準について議論してください、2が)測定施設について説明して、3が、)関連測定が結果として生じると報告して、4が)結果の意味について議論して、他の測定データとそれらを比べて、私たちの測定と手順をまとめるとき5が)提案を募るということです。
I. THE MEASUREMENT CRITERIA
I. 測定評価基準
The FTP (Ref. "The File Transfer Protocol", by Abhay Bhushan, NWG/RFC 354, NIC 10596, ) may be considered a facility for data transfer between file systems. The relevant measurement parameters for a data transfer facility are:
FTP(審判。 Abhay Bhushan、NWG/RFC354、NIC10596による「ファイル転送プロトコル」) ファイルシステムの間のデータ転送のための施設であると考えられるかもしれません。データ転送施設のための関連測定パラメタは以下の通りです。
1) Transfer rate (both peak and average, measured in bits per second) which determines the throughput of the data transfer facility.
1) データ転送施設に関するスループットを測定するレート(bpsで測定されたピークと平均の両方)を移してください。
2) Response time or delay (measured in seconds) which determines the "interactibility" of the facility.
2) 施設の"interactibility"を決定する応答時間か遅れ(秒に測定されます)。
3) Processing cost (measured in dollars or cpu-seconds per megabit transferred) for transferring the data between the network and the file system. This is only one component of the cost of transferring data, the other component being the communication cost (including IMP processing costs) which we take as given.
3) ネットワークとファイルシステムの間にデータを移すために、費用(ドルで測定するか、または1メガビットあたりの何cpu-秒も移す)を処理します。 これはデータ(私たちが与えるように取るコミュニケーション費用(IMP処理コストを含んでいる)であるもう片方のコンポーネント)を移す費用の1つのコンポーネントにすぎません。
4) Failure-to-connect rate - average time elapsed between failures to connect to the facility (measured in hours). Failures could be in the Host (processor and file system) hardware or software, or in the IMPs and telephone lines.
4) 接続しないことのレート--平均時間は施設(何時間も、測定される)に接続しないことの間で経過しました。 失敗がHost(プロセッサとファイルシステム)ハードウェアかソフトウェアか、IMPsと電話回線にあるかもしれません。
5) Availability - the percentage of time a given facility is available, or alternately the probability of finding the facility available at a given time.
5) 時間a当然のことの施設の割合は交互に有効です。有用性--、一時に施設が利用可能であることがわかるという確率。
6) Accuracy - measured by the probability of error in transferring bits, bytes, blocks, or files.
6) 精度--ビット、バイト、ブロック、またはファイルを移すことにおける、誤りの確率で、測定されます。
Bhushan [Page 1] RFC 573 DATA AND FILE TRANSFER September 1973
Bhushan[1ページ]RFC573データとファイル転送1973年9月
II. THE MEASUREMENT FACILITIES
II。 測定施設
The MIT-CMS survey program (ref. "A Report on the Survey Project" by Abhay Bhushan, NWG/RFC 530, NIC 17375) measures the response-time, failure-to-connect rate, and availability of the Host-logger facility (on socket 1). Our preliminary experiments have indicated that the corresponding measurement results for the FTP are very close to that for the logger (at least they are the same order-of-magnitude). As the use of FTP and the ARPANET is increasing rapidly, most Hosts have their logger and FTP operational whenever their Host and NCP (Network Control Program) are functioning. The response time for obtaining the use of FTP service is very close to that for obtaining the use of the logger service as both involve the use of the ICP (Initial Connection Protocol).
MIT-CMS調査プログラム(審判。 Abhay Bhushan、NWG/RFC530、NIC17375が「調査プロジェクトに関するレポート」) 応答時間、接続しないことのレート、およびHost-きこりの施設の有用性(ソケット1の)を測定します。 私たちの予備試験は、FTPのための対応する測定結果が非常にきこりのためのその近くにあるのを示しました(少なくともそれらは大きさの同じ注文です)。 FTPとアルパネットの使用が雨後の竹の子のように出ているのに従って、彼らのHostとNCP(ネットワークControl Program)が機能しているときはいつも、ほとんどのHostsで彼らのきこりとFTPは操作上になります。 FTPサービスの使用を得るための応答時間が非常に両方がICP(初期のConnectionプロトコル)の使用にかかわるのできこりのサービスの使用を得るためのその近くにあります。
Preliminary results from the Survey Project indicate that the average response time in recent months has been about 2.7 seconds. The average availability has been about 85% with the failure-to-connect rate being about once every 10 hours. Table I shows summary results for the time period August 26 through August 31, 1973, for three Hosts with TENEX operating systems (SRI-ARC (NIC), BBN-TENEXA, and USC-ISI).
Survey Projectからの予備の結果は、最近の月で平均応答時間がおよそ2.7秒であることを示します。 平均した有用性はおよそかつて10時間毎である接続しないことのレートのおよそ85%です。 私が8月26日から1973年8月31日までの期間、TENEXオペレーティングシステムがある3Hostsのために概要結果を示しているテーブル(SRI-ARC(NIC)、BBN-TENEXA、およびUSC-ISI)。
The reader is cautioned that the data below reflects the Host performance as seen by the MIT-DMS survey program which surveys the Hosts only once every twenty minutes. Consequently, the actual host performance may be somewhat different. Also, we cannot distinguish between IMP, telephone lines, and Host failures and the response time of a host is affected by its distance (number of IMP hops) from the MIT IMP (IMP 6).
読者は以下のデータが20分に一度だけHostsについて調査するMIT-DMS調査プログラムで見られるHost性能を反映すると警告されます。 その結果、実際のホスト性能はいくらか異なっているかもしれません。 また、私たちはIMP、電話回線、およびHostの故障を見分けることができません、そして、距離(IMPホップの数)でホストの応答時間はMIT IMP(IMP6)から影響を受けます。
In the data shown in Table II, each success or fail response is considered to have a duration of 20 minutes, so Hosts are given the benefit of the doubt for the time we are not surveying. In addition, the response time has been averaged only for the successful logger available responses. The logger is considered available if the SURVEY program can establish a full-duplex connection within 20 seconds. The Host is considered available when it is not in the "DEAD" state (states in which logger is not up but the Host is available are logger not responding and logger rejecting).
Table IIのデータでは、各成功かやり損ない応答には20分の持続時間があると考えられるので、私たちが調査していない時間の疑わしきは罰せずの原理をHostsに与えます。 さらに、応答時間はうまくいっているきこりの利用可能な応答のためだけに平均されました。 SURVEYプログラムが20秒以内に全二重接続を確立できるなら、きこりは利用可能であると考えられます。 それが「死んでいる」状態にないとき(きこりが起きていませんが、ホストが手があいている州は応じるのときこりの拒絶ではなく、きこりです)、Hostは利用可能であると考えられます。
Bhushan [Page 2] RFC 573 DATA AND FILE TRANSFER September 1973
Bhushan[2ページ]RFC573データとファイル転送1973年9月
TABLE I
テーブルI
RESPONSE TIME, AVAILABILITY, AND FAILURE RATE FOR SELECTED HOSTS
(based on SURVEY data for 8/25/73 through 8/31/73)
選択されたホストのための応答時間、有用性、および故障率(8/25/73から8/31/73のSURVEYデータに基づく)です。
PARAMETER NIC BBN ISI
パラメタNIC BBN ISI
Average Response-time (sec.) 2.7 2.4 3.0
平均した応答時間(秒) 2.7 2.4 3.0
Host Availability 93% 85% 87%
有用性を93%85%87%ホスティングしてください。
Logger Availability 91% 79% 83%
きこりの有用性91%79%83%
Failure-to-connect rate
接続しないことのレート
for Host (hours) 18.2 9.4 18.1
ホスト(何時間もの)18.2 9.4 18.1のために
Failure-to-connect rate
接続しないことのレート
for logger (hours) 16.0 6.0 10.0
きこり(何時間もの)16.0 6.0の10.0のために
The details on the above measurements will be reported in a forth- coming paper. This paper will focus on the remaining parameters of transmission rate, processing costs and accuracy, as measured by the MIT-DMS File Transfer Measurement facility.
上記の測定値に関する詳細は先へaで来る紙で報告されるでしょう。 この紙は通信速度、処理コスト、および精度の残っているパラメタに焦点を合わせるでしょう、MIT-DMS File Transfer Measurement施設によって測定されるように。
The FTP measurement facility exists in the MIT-DMS CALICO subsystem. Each time the MIT-DMS FTP-user or FTP-server program in the CALICO subsystem is used to transfer files (and data) via the ARPANET, it records in a local disk file the following transfer parameters: the remote Host involved, the date and time the transfer is initiated, the total number of bits transferred, the real time taken (in seconds) for the transfer, the CPU time (in micro-seconds) used by the program, whether the program is the server or user, and the FTP parameter settings for byte size (BYTE), representation type (TYPE), transfer mode (MODE), and the file structure (STRU). Programs exist in CALICO to display and summarize this data.
FTP測定施設はMIT-DMS CALICOサブシステムで存在しています。 CALICOサブシステムによるMITのDMS FTPユーザかFTPサーバプログラムがアルパネットでファイル(そして、データ)を移すのに使用される各回、以下の転送パラメタをローカルディスクファイルに記録します: かかわったリモートHost、転送が起こされる日時、ビットの総数は移されました、リアルタイムのバイトのために転送、プログラムがサーバかユーザであることにかかわらずプログラムで費やされたCPU時間(マイクロセカンドの)、およびFTPパラメタ設定に取られた(秒の)サイズ(BYTE)、タイプ(TYPE)、転送モード(MODE)、およびファイルが構造化する表現(STRU)。 プログラムは、このデータを表示して、まとめるためにCALICOに存在しています。
It should be noted that no measurements are recorded when the non- CALICO FTP-user and FTP-server programs are used for transferring files. Therefore it should be pointed out that the measurement represents a small subset of our total FTP-usage. The CALICO FTP- server was operated only till May 1973, when we switched to the non- CALICO FTP-server. (The switch was made because CALICO still undergoing development is somewhat less reliable. As CALICO stabilizes we may again operate the CALICO server and continue measuring data transfer.) In addition many users prefer to use the simpler (involving fewer system resources) stand-alone FTP-user
CALICO FTP-ユーザとFTPサーバの非のプログラムがファイルを移すのに使用されるとき、どんな測定値も記録されていないことに注意されるべきです。 したがって、測定が私たちの総FTP用法の小さい部分集合を表すと指摘されるべきです。 私たちであるときに、切り換えられて、CALICO FTPサーバが1973年5月までしか操作されなかった、非、CALICO FTP-サーバ。(まだ開発を受けているCALICOがいくらか信頼できないので、スイッチは作られました。 CALICOが安定しているとき、私たちは、再びCALICOサーバを操作して、データ転送を測定し続けるかもしれません。) さらに、多くのユーザが、より純真な(より少ないシステム資源にかかわる)スタンドアロンのFTPユーザを使用するのを好みます。
Bhushan [Page 3] RFC 573 DATA AND FILE TRANSFER September 1973
Bhushan[3ページ]RFC573データとファイル転送1973年9月
program. The measurement does include the data transferred when FTP is used indirectly by such commands as "copy", "print", "listf", and "mail.file" in the CALICO NETWRK subsystem.
プログラムを作ってください。 測定はFTPがCALICO NETWRKサブシステムで間接的に「コピーする」ようなコマンド、「印刷」、"listf"、および"mail.file"によって使用されるとき移されたデータを含んでいます。
III. THE MEASUREMENT RESULTS
III。 測定結果
The measurement facility has been operational (though not continuously) since 25 February 1973. It has recorded the transfer of 304 files consisting of 57.6 million bits. Over 90% of the bits transferred (but only 75% of the files)used the more efficient Image-36 stream mode (TYPE I, BYTE 36, MODE S) of transfer. The remainder of the files were transferred using the ASCII-8 stream mode (TYPE A, BYTE 8, MODE S). It should be noted that even though block mode was available, it was never used by our users (primarily because many FTP-servers do not implement it, and it is less efficient to use). All the files had a sequential non-record file structure (STRU F). A summary of the measurement results is shown in Table II.
1973年2月25日以来測定施設は操作上です(絶え間なくはありませんが)。 それは5760万ビットから成る304個のファイルの転送を記録しました。 移されたビット(しかし、ファイルの75%だけ)の90%以上は転送の、より効率的なImage-36流れのモード(TYPE I、BYTE36、MODE S)を使用しました。 ASCII-8流れのモード(TYPE A、BYTE8、MODE S)を使用することでファイルの残りを移しました。 ブロックモードが利用可能でしたが、それが私たちのユーザによって決して使用されなかったことに(主として、多くのFTPサーバがそれを実行しないで、またそれが使用するためにそれほど効率的でないので)注意されるべきです。 すべてのファイルには、連続した非レコード・ファイル構造(STRU F)がありました。 測定結果の概要はTable IIに示されます。
TABLE II
テーブルII
SUMMARY OF FTP MEASUREMENT RESULTS
FTP測定結果の概要
Subset of data # Files # bits Av. File Speed CPU-use
Mbits Kbits Kbps sec/Mb
データ#Files#ビットAvの部分集合。 ファイル速度CPU使用メガビットキロビットキロビット毎秒秒/Mb
Total 304 57.6 189 7.56 4
57.6に304を合計してください、189、7.56、4
Image 36 mode 223 53.6 240 9.35 3
36モード223 53.6に9.35に240に像を描いてください、3
ASCII-8 mode 81 4.0 49 2.09 19
ASCII-8モード81 4.0、49 2.09 19
Server sending 62 3.8 61 7.50 2
3.8に61 7.50に62を送るサーバ、2
Server receiving 110 19.8 180 7.44 1
サーバ受信110 19.8 180、7.44、1
User receiving 83 22.8 276 7.92 6
ユーザ受信83 22.8 276 7.92、6
User sending 49 11.1 225 7.09 4
49 11.1に7.09に225を送るユーザ、4
The entire display of the measurement data and the summaries shown in Table II are generated by the "PFTPST" (Print FTP Statistics) program in the CALICO subsystem. A sample of the data displayed is shown in Table III. The BPS (bits per second) and the M/B (CPU microseconds per bit or CPU seconds per Megabit) information is calculated by the displaying program. The largest file transferred was 5.03 Mbits, a "STOR" by the FTP-user to MIT-AI. The transfer took 10 minutes of real time for a transfer rate of a little over 10 Kbps. The highest data transfer rate recorded was 27.8 Kbps, a
測定データの全体の表示と示された概要はTable IIでキャラコサブシステムによる"PFTPST"(FTP統計を印刷する)プログラムで作られます。 表示されたデータのサンプルはTable IIIで見せられます。 BPS(bps)とM/B(1ビットあたりのCPUマイクロセカンドか1MegabitあたりのCPU秒)情報は表示プログラムで計算されます。 移される中で最も大きいファイルは5.03メガビット、FTPユーザによるMIT-AIへの"STOR"でした。 転送は10Kbpsの転送レートのための10分のリアルタイムを取りました。 記録される中で最も高いデータ転送速度は27.8Kbps、aでした。
Bhushan [Page 4] RFC 573 DATA AND FILE TRANSFER September 1973
Bhushan[4ページ]RFC573データとファイル転送1973年9月
"RETR" from BBN-TENEXA to MIT-DMS FTP-server. The length of the file in the above case was 28 Kbits. Needless to say that both of the above transfers used the more efficient Image-36 mode for transfer. The smallest file and the smallest transmission rate recorded was an 80 bit "MLFL" to MIT-ML (using ASCII-8) which took 7 seconds real time for 11 bps transfer rate.
MIT DMS FTPサーバBBN-TENEXAから上の場合における、ファイルの長さまでの"RETR"は28キロビットでした。 上の転送の両方が転送により効率的なImage-36モードを使用したのが言うまでもありません。 最も小さいファイルの、そして、記録される中で最も小さい通信速度は11ビーピーエス転送率における、リアルタイムの7秒取ったMIT-ミリリットル(ASCII-8を使用する)への80ビット"MLFL"でした。
TABLE III
テーブルIII
SAMPLE DISPLAY OF FTP MEASUREMENT DATA
FTP測定データのサンプル表示
-#- ---HOST--- COMM --DATE-- --TIME-- --BITS-- -BPS- M/B T BY PRG
-#- ---ホスト--- PRGによるCOMM(日付)(時間)(ビット)bps M/B T
2 sri-arc STOR 73/08/09 18:19:49 121392 1395 21 I 36 U
198 mit-ml STOR 73/08/15 15:00:30 50688 5336 8 I 36 U
198 mit-ml RETR 73/08/15 15:01:14 50688 10137 12 I 36 U
198 mit-ml STOR 73/08/15 15:02:33 255456 8808 7 I 36 U
198 mit-ml RETR 73/08/15 15:03:58 258048 8601 12 I 36 U
134 mit-ai STOR 73/08/15 15:13:17 286720 1898 29 A 8 U
134 mit-ai RETR 73/08/15 15:18:39 258048 9557 14 I 36 U
134 mit-ai STOR 73/08/15 15:19:42 258048 6974 7 I 36 U
2 sri-arc RETR 73/08/15 15:31:20 7236 3618 22 I 36 U
2 sri-arc STOR 73/08/15 15:32:55 49428 8238 31 I 36 U
2 sri-arc RETR 73/08/15 15:34:56 49428 3530 15 I 36 U
2 sri-arc STOR 73/08/15 15:38:09 49428 7061 8 I 36 U
2 sri-arc STOR 73/08/20 15:18:26 35460 2364 9 I 36 U
2 sri-arc RETR 73/08/20 16:08:09 58832 426 153 A 8 U
2 sri-arc RETR 73/08/22 12:46:10 10512 166 247 A 8 U
2 sri-arc RETR 73/08/23 16:29:37 320 64 369 A 8 U
2 sri-arc RETR 73/08/24 12:25:38 9992 262 254 A 8 U
2 sri-arc RETR 73/08/24 12:27:26 9992 454 250 A 8 U
198 mit-ml STOR 73/08/29 10:40:58 768924 7538 7 I 36 U
198 mit-ml STOR 73/08/29 10:44:09 166572 5552 7 1 36 U
198 mit-ml STOR 73/08/29 10:54:32 166572 7932 7 I 36 U
198 mit-ml STOR 73/08/29 13:48:18 158040 12156 7 I 36 U
69 bnn-tenexa MLFL 73/08/29 22:30:55 5600 1866 51 A 8 U
69 bbn-tenexa MLFL 73/08/29 22:31:42 5600 2800 50 A 8 U
86 usc-isi MLFL 73/08/29 22:33:55 5600 1400 54 A 8 U
69 bbn-tenexa MLFL 73/08/29 22:36:15 5600 2800 48 A 8 U
69 bbn-tenexa MLFL 73/08/29 22:36:54 5600 2800 49 A 8 U
2 様アークSTOR73/08/09の18:19:49 121392 1395 21I36U198mit-ミリリットルSTOR73/08/15の15:00:30 50688 5336 8I36U198mit-ミリリットルRETR73/08/15の15:01:14 50688 10137 12I36U198mit-ミリリットルSTOR73/08/15の15:02:33 255456 8808 7I36U198mit-ミリリットルRETR73/08/15の15:03:; 58 258048 8601 12I36U134mit-ai STOR73/08/15の15:13:17 286720 1898 29A8U134mit-ai RETR73/08/15の15:18:39 258048 9557 14I36U134mit-ai STOR73/08/15の15:19:42 258048 6974 7I36U2様アークRETR73/08/15の36U2様アークSTOR73/08/15の15:31:20 7236 3618 22I15:; U198mit-ミリリットルSTOR73/08/29の10:44:09 166572 5552 7 1 36U198mit-ミリリットルSTOR73/08/29の10:54:32 166572 7932 7I36U198mit-ミリリットルSTOR73/08/29の13:48:18 158040 12156 7I36U69bnn-tenexa MLFL73/08/29の22:30:55 5600 1866 51A8U69bbn-tenexa MLFL73/08/29の22:31:42 5600 2800 50A8U86usc-isi MLFL73/08/29の22:33:55 5600 1400 54A8U69bbn-tenexa MLFL73/08/29の22:36:15 5600 2800 48A8U69bbn-tenexa MLFL73/08/29の22:36:54 5600 2800 49A8、U
It should be pointed out that recent measurement data for ASCII-8
transfer includes retrieval of "NIC Journal" documents
("<Xjournal>xxxxx.nls;xnls" files) from SRI-ARC. SRI-ARC converts
these "xnls" files from NLS to sequential form on the "fly" and this
takes considerable time giving a low transfer rate for these
transfers.
ASCII-8転送のための最近の測定データが「NICジャーナル」というドキュメントの検索を含んでいると指摘されるべきである、(「<Xjournal>xxxxx.nls;、xnls、」 ファイル) SRI-ARCから。 SRI-ARCは「ハエ」でNLSから連続したフォームまでこれらの"xnls"ファイルを変換します、そして、これは、低転送率にこれらの転送を支払いながら、かなりの時間がかかっています。
Bhushan [Page 5] RFC 573 DATA AND FILE TRANSFER September 1973
Bhushan[5ページ]RFC573データとファイル転送1973年9月
In transferring files we found the ARPANET and the FTP to be quite reliable. On numerous occasions we transferred complete listing of our operating system (about 6 million bits), reassembled it and ran it with no problem. No data lossage problems have been reported to us as yet.
ファイルを移す際に、私たちは、アルパネットとFTPがかなり信頼できるのがわかりました。 多数の時に、私たちは、問題なしで私たちのオペレーティングシステム(およそ600万ビット)の完全なリストを移して、それを組み立て直して、それを走らせました。 データlossage問題は全くまだ私たちに報告されていません。
IV. THE SIGNIFICANCE OF MEASUREMENT RESULTS
IV。 測定結果の意味
First of all let me state my complete agreement with Barry Wessler (Ref. "Revelations in Network Host Measurements" NWG/RFC 557, NIC 18457) that the measurement results should be taken in the spirit: "Here is a place to make the Network better" rather than: "Look, isn't the Network terrible." We take these measurements in the same spirit and have found the measurement effort to be quite fruitful. In several instances, with the aid of our measurement facilities, we have been able to improve the performance of our Network programs by an order-of-magnitude (just as Don Allen at BBN improved Greg Hicks' RJS program).
まず、バリーWesslerとの完全な同意を述べさせてください。(審判。 「ネットワークホスト測定値における示現」NWG/RFC557、NIC18457) 精神で測定が結果として生じるのを取るべきです: 以下のというよりむしろ、「ここに、Networkをより良くする場所があります」。 「ほら、Networkはひどくはありません」? 私たちは、同じ精神におけるこれらの測定を取って、測定が全く実り多くなるためには努力であることがわかりました。 いくつかの例では、私たちの測定施設の援助で、私たちは私たちのNetworkプログラムの1桁の性能を向上させることができました(ちょうどBBNのドン・アレンがグレッグ・ヒックスのRJSプログラムを改良したように)。
Our measurement results are in close agreement with the BBN FTP measurements (8.2 cpu seconds/Mb for 8-bit byte and 2 CPU seconds/Mb for 36-bit byte transfers). We also find the 36-bit byte transfer to be an order-of-magnitude more efficient than 8-bit byte transfer. The processing cost (assuming $6.00 per CPU minute) for transferring a Megabit of information comes to about $1.90 for ASCII-8 mode as compared to only $0.30 for Image-36 mode. The difference in transfer rate is equally astounding being 9.4 Kbps for Image-36 as compared to only 2 Kbps for ASCII-8.
BBN FTP測定値との厳密な合意には私たちの測定結果があります(36ビットのバイトのための8ビットのバイトと2CPU秒/Mb8.2cpu秒/Mbは移されます)。 また、私たちは、36ビットのバイトが8ビットのバイト転送より1桁効率的である転送であることがわかりました。 移すためのImage-36モードのために0.30ドルだけと比べて、情報のMegabitがASCII-8モードの1.90ドルに関して来る加工費(CPU分あたり6.00ドルを仮定します)。 転送レートの違いは、Image-36のための9.4KbpsであるのでASCII-8のために2Kbpsだけと比べて、等しく驚かせています。
It is therefore recommended that Image-36 mode be used as much as possible to transfer data between PDP-10s (of which there are many on the ARPANET). It is strongly urged that protocols and programs allow (and use) the Image-36 mode for all data transfers including mailing files (MLFL), listing directories (LIST, NLST), and sending/retrieving NIC Journal documents. Many of the MID-DMS user programs such as "COPY" and "FTP" take advantage of the fact that the remote Host is a PDP-10 (there is a table of PDP-10's in "COPY") and use the more efficient Image-36 mode. Such a procedure is highly recommended.
したがって、Image-36モードが10PDP-年代(そこには多くがアルパネットにある)の間にデータを移すのにできるだけ使用されるのは、お勧めです。 促されて、プロトコルとプログラムがファイル(MLFL)を郵送するのを含むすべてのデータ転送のための(そして、使用)Image-36モードを許容するのは、強くそうです、NIC Journalドキュメントをディレクトリ(LIST、NLST)をリストアップして、送るか、または検索して。 「コピー」や「FTP」などのMID-DMSユーザ・プログラムの多くが、リモートホストがPDP-10(「コピー」にはPDP-10のテーブルがある)であるという事実を利用して、より効率的なイメージ-36モードを使用します。 そのような手順は非常にお勧めです。
The effective IMP-IMP data transfer rate is about 37.5 Kbps over the 50 Kbps telephone line (Ref. McQuillan John M., "Throughput in the ARPA Network--Analysis and Measurement," BBN Report 2491, NIC 14188, January 1971). The Host-to-Host data transfer measurement performed by BBN (above reference, p. 28) have indicated a transfer rate of 30-35 kbps BBN-to-BBN (0 IMP hops) and 12-16 Kbps BBN-to-SRI (5 hops) using single link. As FTP transfers data via a single link, a maximum transfer rate between 12 and 35 Kbps (depending on number of
有効なIMP-IMPデータ転送速度は50Kbps電話回線の上のおよそ37.5Kbpsです。(審判。 マッキラン・ジョンM.、「アーパネットのスループット--、分析と測定、」、BBNレポート2491、NIC14188、1971年1月). Hostからホストへのデータ転送BBNによって実行された測定(参照、pの上で。 28) 単一のリンクを使用することで30-35 キロビット毎秒BBNからBBN(0つのIMPホップ)と12-16のKbps BBNからSRI(5つのホップ)の転送レートを示しました。 FTPが移されるとき、単一のリンクを通したデータ、最大の転送が12〜35Kbpsを評定する、(数に依存します。
Bhushan [Page 6] RFC 573 DATA AND FILE TRANSFER September 1973
Bhushan[6ページ]RFC573データとファイル転送1973年9月
IMP hops) can be expected if that file transfer is the only activity going on. In this light our maximum transfer rate of 27 Kbps to BBN (2 hops) is probably the most one can expect out of any program. The average transfer rate of 9.4 Kbps (for Image-36) transfer also appears reasonable in view of the fact that during many of the transfers other network activity is also going on, and that many of the transfers are performed when the respective computer systems are quite heavily loaded. Our measurement data does reveal that transfer rate is appreciably higher during the times a computer is likely to be lightly loaded.
IMPホップ) そのファイル転送が先へ進む唯一の活動であるなら予想できます。 この光の中では、私たちのBBN(2つのホップ)への27Kbpsの最大の転送レートはたぶんものがどんなプログラムからも予想できる大部分です。 また、9.4Kbps(Image-36のための)の転送の平均した転送レートはそれぞれのコンピュータ・システムが全く大いにロードされるとき、他のネットワーク活動がまた、先へ進んで、そんなに多い転送の多くの間転送が実行されるという事実から見て妥当に見えます。 私たちの測定データは、転送レートがコンピュータが軽くロードされそうであるという回の間かなり高いのを明らかにします。
The above does not mean that improvements are not possible or not required in the state of the ARPANET data transfer. Our measurement data has revealed areas in which improvements can be and should be made. For example, the transfer of data to other MIT Hosts (0 IMP hops) and back to ourselves should be faster than what we currently achieve (transfer to BBN is faster!). The probable reason for the above discrepancy is that our allocation (Host-Host protocol) is very small (2944 bits) as compared to that provided by BBN (17724 bits). This means that to transfer data our Network Control Program (NCP) has to wait for an allocation many more times while communicating to an ITS system than to a TENEX system. Large allocations are always desirable but even more so while transferring files. NCP designers can (and should) modify NCP's to allow large allocates (larger NCP buffers) for file transfer even at the expense of smaller allocates for other types of connections (such as a terminal connected to a computer system) which do not require or use the larger allocation. In addition, a new allocate should be sent as soon as data is read by the receiving program (the NCP should not wait for the allocation to become zero before sending the new allocate).
上記は、改良がアルパネットデータ転送の状態で可能でないか、または必要でないことを意味しません。 私たちの測定データは改良があることができて、されるべきである領域を明らかにしました。 例えば、他のMIT Hosts(0つのIMPホップ)と、そして、自分達へのデータ転送は私たちが現在達成することより速いはずです(BBNへの転送はさらに速いです!)。 上の食い違いのありえそうな理由はBBN(17724ビット)によって提供されたそれと比べて、私たちの配分(ホスト兼ホストプロトコル)が非常に小さいという(2944ビット)ことです。 これは、データを移すために、私たちのNetwork Control Program(NCP)がITSシステムに伝えている間TENEXシステムよりずっと多くの回配分を待たなければならないことを意味します。 大きい配分は、ファイルを移している間いつも望ましいのですが、さらにそうです。 より小さいことを犠牲にしたさえファイル転送が他のタイプの接続(コンピュータ・システムにつなげられた端末などの)のために、より大きい配分を必要でない、または使用しないものを割り当てるので、デザイナー缶の(and should)が多、を許容するようにNCPのものを変更するNCPは(より大きいNCPバッファ)を割り当てます。 追加、aで新しい、割り当て、データが受信プログラムで読まれると(NCPは、配分が新しさが割り当てる発信の前にゼロになるのを待つべきではありません)すぐに、送るべきです。
We also observed that small files are transferred at a significantly lower transfer rate than large files but beyond a file size of 40 Kbits, the file size makes little difference in transfer rate or processing cost per bit transferred. The figure of 40 Kbits is probably related to the size of sending and receiving buffers used by the programs. In general, for most practical values of buffer size, the larger the buffer size and allocations, the faster and more efficient will be the transfer. Unfortunately, large NCP buffers are not easily available in many systems and come at a premium. The information on average file size (240 Kbits for Image and 40 Kbits for ASCII files) may be helpful in optimum allocation of buffer space.
また、私たちが、大きいファイルよりかなり低い転送レートで小さいファイルを移しますが、40キロビットのファイルサイズを超えて、ファイルサイズは転送レートでは大差がないのを観測したか、または1ビットあたりの加工費が移されました。 40キロビットの図はたぶんプログラムで使用される送受信バッファのサイズに関連します。バッファサイズのほとんどの実用的な値には、一般に、バッファサイズと配分が大きければ大きいほど、転送は、より速くて、より効率的になるでしょう。 残念ながら、大きいNCPバッファは、多くのシステムで容易に利用可能でなく、プレミアムで来ます。 平均したファイルサイズ(Imageのための240キロビットとASCIIファイルのための40キロビット)の情報はバッファ領域の最適な配分に有用であるかもしれません。
Bhushan [Page 7] RFC 573 DATA AND FILE TRANSFER September 1973
Bhushan[7ページ]RFC573データとファイル転送1973年9月
V. REQUEST FOR COMMENTS AND SUGGESTIONS
V。 コメントと提案を求める要求
It is hoped that the above measurement results and our FTP and SURVEY measurement facilities will help ARPANET users plan their modes of Network usage and help Network programmers in making the Network better. This RFC is indeed a Request For Comments and your suggestions on the way we collect, store, and display measurement data will be greatly appreciated. We can break the measurement data by Hosts and will be happy to provide the information if it is considered desirable. Please let me know what other parameters we should record or display. You may communicate with me via the ARPANET (AKB at MIT-DMS (Host 70), NIC Ident AKB), via telephone (617-253-1428 or 1449), or US mail (Rm. 208, 545 Tech Square, Cambridge, Mass 02139).
私たちの上の測定結果、FTP、およびSURVEY測定施設が、アルパネットユーザが彼らのNetwork用法のモードを計画しているのを助けて、NetworkプログラマがNetworkをより良くするのを手伝うことが望まれています。 本当に、このRFCはRequest For Commentsです、そして、私たちが測定データを集めて、保存して、表示する方法における提案に大いに感謝するでしょう。 Hostsで測定データを知らせることができて、それが望ましいと考えられると、情報を提供するでしょう。 私たちがどんな他のパラメタを記録するべきであるか、または表示するべきであるかを私にお知らせください。 アルパネット(MIT-DMS(ホスト70)のAKB、NIC Ident AKB)であなたは私にコミュニケートできます、電話(617-253-1428か1449)、または米国メールで(Rm。 208 545の科学技術の正方形、ケンブリッジは02139を一かたまりにします。).
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Robert Baskerville 9/98 ]
[このRFCはエントリーのためのマシンに入れられた読み込み可能なフォームでした][ロバート・バスカーヴィル9/98によるオンラインRFCアーカイブへの]
Bhushan [Page 8]
Bhushan[8ページ]
一覧
スポンサーリンク
