- - PR -
帯域幅遅延積について
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-07-18 16:32
そうみたいですね。 測定結果ありき、なのか、理論ありき、なのかで。
およそ2倍で十分、と私は認識しています。
何か答えが出たならよかったですね。 ところで。 オススメどおりIperfを使って私も測定してみました。 それほどいろいろ試したわけではありませんが、 ネットワークを変えて数パターン試した結果、 どの場合も帯域幅遅延積の1.2倍程度のバッファがあれば転送速度は飽和しました。 BDPの10倍も必要というのは何かおかしいと思いますよ。 エンドの処理能力が帯域幅に追いついていないのではないかと。 その状態だと帯域幅遅延積ではバッファが足りないとか そういう類の話とはだいぶ次元が違うかなと思います。 | ||||||||||||
|
投稿日時: 2008-07-18 16:33
ネットワーク(中継機器を含む)の純粋なスループットは、おそらく導入業者が先に測っていると思いますが、自分が使うマシンを含めたスループットは自分で測るしかなく、最適なバッファサイズなどもそれぞれ異なるはずです。
環境依存なので、何倍なら十分という話は意味がありません。 10倍取る場合もあるし、2倍で十分な場合もある。 vistaの次世代TCP/IPスタックやautobuf等の技術もあるので、 ソースがあれば(さらにソースを読み解く腕があれば)調べてみてもいいかも。 帯域幅遅延積はあくまで目安であって、最適値ではありません。 理論的にはその値が最高値ですが、その他の因子が強い環境では それに合わせたチューニングが必要になるでしょう。 この辺はOSのパラメタをどれだけ知っているかとか、プログラミングでコストを最小にするように気を配るなども必要になってくると思います。 帯域幅遅延積が効いてくるのはおそらくWANやMANであり、遅延が小さいLANの様な環境ではあまり意味を成さないでしょう。 スレ主はロングファットパイプな線を使っているんだと思いますが、 プログラムによって動的に決定する方法があれば楽ですね。 | ||||||||||||
|
投稿日時: 2008-07-18 16:48
>BDPの10倍も必要というのは何かおかしいと思いますよ。
>エンドの処理能力が帯域幅に追いついていないのではないかと。 > >その状態だと帯域幅遅延積ではバッファが足りないとか >そういう類の話とはだいぶ次元が違うかなと思います。 別に10倍も必要ではありませんが、まさにそのとおりです。 LFNなため、ぜんぜん追いつきません。 チューニングパラメタはそのときそのときで動的に決定できるのが 望ましいですが、現状のTCPでは一度リッスンソケットに接続するともう変更できないので不可能です。 確かにvistaは調べてみたいですが、どこかに文献かソースは無いですかね・・・ ソースは無理だろうなぁ [ メッセージ編集済み 編集者: トム 編集日時 2008-07-18 17:00 ] | ||||||||||||
|
投稿日時: 2008-07-18 17:25
しかし、バッファを大きく取れば900Mbps以上出るのであれば、 追いついていないというのは変ですね。 追いついていないのであれば、バッファを10Mbyteで取ったとしても、 100Mbyteのデータを送る場合には少なすぎて900Mbpsも出せないでしょう。 Iperfってマルチスレッドで複数ソケットはれるから、16ソケットを並行でやったりすれば、それぞれのソケット分TCPスタックが働いて、マシンが苦しくなるけど受信性能は上がります。そのことかな? | ||||||||||||
|
投稿日時: 2008-07-18 23:29
> エンド依存の面もあるということがわかっただけで十分です。
十分と満足せずに、 時間があるならもっと原因を追究して欲しいところ。 ソケット周りの不具合が出るかもしれませんし。 広告ウィンドウのサイズをモニターしてみたらどうでしょう? 本当に減っていますか? | ||||||||||||
|
投稿日時: 2008-07-19 10:53
ウィンドウ広告値がたとえ4k以上だったとしても、それを見てOSがパケットを送り始めるまでに若干遅延があります。
それをトータルするとネットワークの性能を使いきれないくらいのロスになることもあります。パラで送信した方が速いのはそういうことがあるから。 LFN(LNP)はそういう問題をはらんでいます。 | ||||||||||||
|
投稿日時: 2008-12-25 22:27
ちょっと前までこれに関係した仕事をしていたので、
ちょっとコメントします。 帯域幅遅延席はあくまで理論値です。 ウィンドウをこの値まで使い切れれば最大のスループットが得られます。 しかしながら、実際には送信側の輻輳ウィンドウをどれだけ 大きく取れるかにかかっています。 1〜2回の再送で輻輳ウィンドウは大幅に減ってしまい、 回復するにも膨大な時間を要します(RFC参照 RFC3649とか)。 なので、受信ウィンドウをどんなに大きくしても意味無いです。 SACKが効いているでしょうから、スループットが下がることもないでしょうけど。 てっとり早く速くしたいなら輻輳回避アルゴリズムを HighSpeedTCPやscalableTCPにしてみるとか手はありますが、 fairnessじゃなくなるので、専用線で自分で独り占めできる方以外には あまりお勧めしません・・・ |