確認応答を待たずに送り出す
バッファ・サイズというのはNetperfの測定パラメータの一つ。受け取ったデータを一時的に保存するバッファ・メモリーの設定値である。デフォルトは8K（8192）バイトだが，オプションの設定で自由に変更できる。先ほどのデスクの指摘は，デフォルトの8Kバイトという数値がギガビット・イーサネットの通信には小さすぎるのではないだろうか，という意味だ。
バッファ・サイズがスループットに影響する可能性があるのは，TCPのしくみと関係がある。
TCPは，送り出したパケットごとに相手から確認応答を受け取って，通信の信頼性を確保する。ただ，このしくみはスループットを落としてしまう。送信側に無駄な待ち時間が生じてしまうからだ。
確認応答パケットが送信元に届くには，パケットが相手に届き，相手のパソコンの中で処理されて確認応答が戻ってくるまでの1往復分の時間がかかる。その間，送信側は何もできない（図5[拡大表示]）。これでは，伝送速度をどんなに高速にしてもスループットは上がらない。
そこで，実際のTCPでは，あらかじめ決めた一定量のデータまでは確認応答を待たずに送る（図5の下）。こうすれば送信側は待ち時間なくデータを送り続けられる。
確認応答を待たずに送れるデータ量をウインドウ・サイズと呼ぶ。通信回線が高速なほどウインドウ・サイズを大きく設定するが，大きければ大きいほどよいというわけではない。大き過ぎる値を設定すると，受信側で受け取り切れなくなるからだ。パケットが失われると，再送処理が発生するので，スループットはむしろ悪化する。
そこでTCPではいくつかの要素から最適なウインドウ・サイズを算出し，調整しながら通信する。これがTCPのウインドウ制御だ。
このとき，受信側のバッファ・メモリーの大きさはウインドウ・サイズを決める重要なパラメータの一つになる。バッファ・サイズを大きめに設定すると，TCPはウインドウ・サイズを大きく取れる。ギガビットの通信に合わせたウインドウ・サイズが使われることで，もっと高いスループットが出せるかもしれない。
バッファ・サイズを変えてみる
ということで，Netperfでサーバー側のバッファ・サイズをデフォルトの8Kバイトから，16K，32K，64K，128Kと変化させてスループットがどこまで出るのか測定してみた（図6[拡大表示]）。クライアント側パソコンにはPentium4マシンを使った。ギガビット・アダプタには，USB2.0用，コレガ製とインテル製の32ビットPCIカード＊，さらにCSAで接続されているパソコン内蔵のギガビット・イーサネット・ポートの合計4種類を使った。
結果は予想通りで，バッファ・サイズが大きいほど，スループットは向上した。特にその効果が顕著だったのは，CSA接続とインテル製（チップもインテル製）のPCIカードの二つ。バッファ・サイズが64Kバイトのときに約840Mビット/秒を記録した。
一方，リアルテック製のチップ＊を使ったコレガのPCIカードは，最大480Mビット/秒と，コレガのコメントに近い値を記録した。USB2.0接続のアダプタは，やはりUSBの転送速度がネックになるようで，バッファ・サイズを上げても，190Mビット/秒で頭打ちになった。
| < | 前回へ | 目次 | 次回へ | > |
