イーサネットのスループットが低い場合や、あるいは ftp を用いた転送 速度を少しでも上げるために活用できるヒントを集めました。
ttcp.c プログラムは素のスループットを測定するためにはよい
テストです。他の一般的な方法としては ftp> get large_file /dev/null
の実行があります。ここでの大きなファイル(large_file) とは 1MB
以上のサイズで、なおかつ送信側マシンのバッファ上に残っている必要が
あります。(「get」を少なくとも 2回行ないます。なぜなら 1回目で送信側
マシンのバッファにキャッシュさせるためです。)バッファにキャッシュ
されたファイルを使用するのは、測定結果にディスクの読み込み速度を
含めないためです。転送されたデータの受信先をディスクではなく
/dev/nullにするのも同様の理由です。
8 ビットのカードでさえ、次から次へとやってくるパケットをすき間なく受信 することが可能です。問題となってくるのは、次に受信するパケットのために 十分な余裕を作れるだけの速さでコンピュータがカードからパケットを取り 出せなくなってきた場合です。コンピュータが既に受信したパケットをカード 上のメモリからすばやく取り出せない場合、カード上には次のパケットを受信 するための場所がなくなってしまいます。
この場合、カードは新しいパケットを取りこぼすか、以前受信したパケットの 先頭に上書きしてしまいます。どちらの場合も、パケットの再送を引き起こし たり要求することになり、円滑なデータの流れの邪魔になってしまいます。 ひどい場合は、性能が理論値の 1/5 になってしまうこともあります。
より多くのメモリを搭載しているカードは、より多くのパケットを「バッファ する」ことができます。そのため次から次と受信したパケットを取りこぼすこと なく連続して取り扱うことができます。これは逆に、パケットの取りこぼしを 防ぐための、バッファからパケットを取り出すのに必要なコンピュータの待ち 時間が短くて済むということを意味します。
ほとんどの 8 ビットカードは 8kB のバッファを持っていて、16 ビットのカー ドは 16kB のバッファを持っています。ほとんどの Linux のドライバはバッ ファのうち 3kB を(2つの送信バッファのために)保存しています。そのため 8 ビットカードについては受信用に 5kB だけが残っています。これはフルサ イズ(1500バイト)のイーサネットパケットを 3 つ受信するだけなら十分な量 です。
上述のように、パケットがカードから十分速く取り出されていれば、受信 するパケット用のバッファが小さくてもパケットの取りこぼしやオーバーラン は起こりません。カードからコンピュータのメモリへパケットが取り出されて いく速度を決定する要素は、カードとメモリの 2つを結ぶ経路、すなわち ISAバス上のデータ転送速度です。(CPUが非力な 386SX-16MHz なら、これも 速度に影響を与えます。)
推奨されている ISA バスのクロック数はおよそ 8MHz ですが、多くのマザー ボードと周辺装置はそれより速い周波数で動作することが可能です。ISA バス のクロック数は通常 CMOS の設定において行い、マザーボードと CPU のクロック 数の約数を選択します。ただしいくつかの ISA と PCI/ISA のマザーボード はこのオプションを持っていないかもしれません。その場合は工場出荷時の 設定をそのまま使うことになります。
例として、TTCPプログラムを用いて測定した結果を以下に示します。これは 40MHzの 486に古い 8bit WD8003EPカードを使用したという条件で、ISAバス の速度を変えています。
ISA バス速度 (MHz) Rx TTCP (kB/s)
------------------- --------------
6.7 740
13.4 970
20.0 1030
26.7 1075
TCP/IPを使用する限りは、いかなる 10MB/s のカードを持ってしても 1075kB/s 以上の速度を出すのは難しいでしょう。しかし、どんなシステム でも ISA バスが高速で動作するとは限りません。ほとんどのシステムでは 13MHz 以上の速度では正常に動作しないのです。(また、いくつかの PCI システムでは ISA バスの速度が 8MHzに固定されています。そのためエンド ユーザがそれを増やすことはできません。)
高い転送速度のほかには、メモリとディスクの I/O 転送サイクルが短くなる ことによって CPU 使用率を減らせるという利点もあります。(ISA バス上の ハードディスクとビデオカードも、ISA バスの速度を上げることにより性能が 向上します。)
ISA バスの速度を 8MHz より高くしてみる前に、必ずデータをバックアップし てください。そして、全ての ISA 周辺機器の速度を向上 させた後でも正常に動作することを徹底的にテストしてください。
繰り返しになりますが、搭載している RAM が少ないカードと、コンピュータ のメモリとカード間のデータ転送速度が遅いマザーボードとの組み合わせは、 トラブルの原因となります。TCP 受信ウィンドウの初期値は 32kB になって いますが、これは同じサブネットに存在する高速なコンピュータがよどみ なく 32kB のデータをダンプするような速さでデータを受信するように見せ かけるためです。
最近のバージョンの route コマンドでは、実行中にこのウィンドウの
サイズを設定することができます。通常このウィンドウのサイズを減らさ
なければならないのはローカルネットの場合だけです。なぜならルータ
やゲートウェイの内側に位置するコンピュータは、問題を引き起こさない
程度に「バッファされている」からです。使用例としては:
route add <whatever> ... window <win_size>
win_size は使用したいウィンドウサイズ(バイト単位)です。ISA
バス上の 10MHz かそれ以下で動作している 8 ビットの 3c503 カードは、お
よそ 4kB のウィンドウサイズで良好に動作します。一方でウィンドウサイズ
を大きくしすぎればオーバーランやパケットの取りこぼしを引き起こしかね
ません。その結果イーサネットのスループットは著しく低下してしまいます。
生じている取りこぼしやオーバーランの状況は cat /proc/net/dev
によりチェックできます。
NFSクライアントとして 8 ビットのカードを 8kBの NFSパケットサイズ (Sun 純正)で使用した場合に、期待したほどの性能が出ないことを発見した人 がいます。
理由として考えられるのは、8 ビットと 16 ビットのカードが搭載しているバッ ファサイズの違いによるものでしょう。イーサネットパケットの最大サイズは およそ 1500 バイトです。8kBの NFS パケットが 6 個の連続した最大サイズ のイーサネットパケットとしてやってきたとします。8 ビットでも 16 ビット でもカードが連続したパケットを受信するのは問題ありません。問題はカード のバッファからパケットが順次取り出されていかなくなったときに生じます。 バッファがあふれてしまうのです。8 ビットカードが転送ごとに余分な ISA バスサイクルを必要とするのも困りものです。8 ビットカードを使用している 場合の解決策は、NFS の転送サイズを 2kB(もしくは 1kB)にするか、ISAバス の速度を上げてカードのバッファからパケットを取り出すところを高速にする か、のどちらかです。私の実験では、8MHzで動作する古い WD8003E カードで も、システムにその他の負荷がない場合には 2kB という大きな NFS の転送サ イズでの受信が可能でした。しかし 4kB では、性能がほぼ 1/3 に低下してし まいます。
一方で、少なくとも 16 ビットの ISAカードを使っていて、マウントオプション で転送サイズの初期値が 1kB になっている場合は、転送サイズを 4kB (もしくは 8kB) に設定することによって、性能の向上が期待できます。