- - PR -
帯域幅遅延積について
| 投稿者 | 投稿内容 | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2008-06-02 18:33
ネットワークの帯域にラウンドトリップタイムをかけたもの
帯域幅遅延積となり、送信側が一度に流せるバッファサイズとなります。 つまり受信側のウィンドウサイズのことですが、 実際にこの計算を行ってバッファサイズを計算してみたら、 意外に性能が出ないことが分かりました。 帯域：1Gbps 遅延：15ms 受信バッファサイズ：1Gbps * 15ms = 1.875Mbyte 測定方法：Iperfによるスループットの測定 これで測定してみると400Mbps位しか出ません。 バッファサイズを10Mbyteにすると、900Mbps位でます。 Iperfはメモリ-to-メモリでデータをクライアントからサーバに送るので、 クライアントのバッファサイズやディスクの性能はあまり関係ありません。 スティーブンスなどでは上記の式で理論上最大のバッファサイズが得られるように 書いてありますが、実際にはその数倍の大きさがいるようです。 何か理由があるのでしょうか？ | ||||||||||||
|
投稿日時: 2008-06-02 21:45
コンバンハ
素人ですが、遅延が15msで計算してみました。 一度の転送(1.875MBytes)に必要な時間。15ms+(1.875MB*8/1000Mbps) = 30ms 最大転送できる回数 = 1000ms / 30ms = 33回 33*1.875MBytes = 61.875MByes/s = 495Mbits/s 一度の転送(10MBytes)に必要な時間。15ms+(10MB*8/1000Mbps) = 95ms 最大転送できる回数 = 1000ms / 95ms = 10.52回 10.52*10MBytes = 105.2MByes/s = 841Mbits/s フロー制御の回数が増えれば転送時間に対して遅延時間の割合が増えるから 速度が遅くなるのはあたりまえのような、気がするんですが専門家ではないので 認識に間違いがあるかもしれません。 | ||||||||||||
|
投稿日時: 2008-06-26 04:29
全体に用語が変で、意図がうまく伝わりません。 ウィンドウサイズを設定したのかバッファサイズを設定したのかよくわかりません。 バッファというのがどこのバッファなのかもわかりません。 また受信側のウィンドウサイズと送信側が流せるバッファサイズも違うものです。
理論上「最適」のウィンドウサイズです。 「遅延に対する補償」という観点では ウィンドウサイズを帯域幅遅延積以上にしても意味がありません。 送信バッファが空になった際に、 最後のセグメントに対するACKが来るまで次のデータを送らない、 という実装になっていると、 ネットワークは半分の時間を休んでいることになり、 帯域幅の半分しか速度がでません。 バッファの使用量の時間平均も50%となります。 帯域幅の半分弱の400Mbpsということなので、 上記のような理由で遅くなっているのでしょう。 Iperfは使ったことが無いので知りませんが、 そのあたりを確認するといいと思います。 当然、輻輳制御が入っているなら ウィンドウサイズは主にそれで制御されてしまうので 全く違う話になります。 | ||||||||||||
|
投稿日時: 2008-07-18 13:51
話の流れからここでいうバッファサイズとは受信側(server)の受信バッファのことだということはネットワークを知っている方なら通じていると思われます。
送信側(client)や送信バッファを設定してもここでは性能にほとんど効きませんので。 で、最後のセグメントに対するackが帰ってくるまで待つというのはそうなのですが、 実際には広告windowが適度な大きさになるまで送信側は待たなければなりません。 広告windowの値は受信側の処理能力に依存するはずなので、 BDPを求めてそのまま設定しても全体のスループットは最大にならないということです。 この「ある程度の大きさになるまで」の待ち時間はRTTには現れないので、 この分を見積もる必要があるのではないかと思われます。 NO_DELAYをONにすると速くなるのかもと思いましたが、バルクデータの送信にはあまり効果が無いようです。 結局、BDPはネットワークの線の性能のMAX値であって、エンドエンドの能力は別問題ということということになるんでしょう。 [ メッセージ編集済み 編集者: トム 編集日時 2008-07-18 14:02 ] | ||||||||||||
|
投稿日時: 2008-07-18 15:17
私には通じませんでしたが、そういうものなのですね。
ネットワークの速度を問題にする場合、 受信側や送信側は十分な処理速度を持つ状態で測らないと意味がありません。 Iperfというがネットワークのスループットを測定するソフトなら、 受信側バッファを一杯にしておくようなことなど無いと思います。 速度を測るだけですからバッファに用は無く、廃棄すればいいだけですから。
前にも書いたように、 帯域幅遅延積分のバッファがあれば遅延を保障できるというだけです。 パケットロスがあったり受信側・送信側で処理が滞っているなら、 遅くなるのは当然です。 そういったことに留意して測定したのであれば、 帯域幅遅延積のせいぜい2倍程度のバッファがあれば十分なはずです。 バッファが数倍ないと本来の性能が出ないというのはおかしいです。 スロースタートしてる最中に測ってしまっているとか、 測定の方法を間違っているとか、 何かおかしいことになっていると思います。 | ||||||||||||
|
投稿日時: 2008-07-18 15:38
着目しているところが違うようなので、話がかみ合っていません。
Iperfにはバッファサイズを変えたりソケット数を増やしたりして、 実測値を出すことができます。 実際に動かしてみるとわかると思いますよ。 私の環境ではBDPの２倍ではまったく足りませんでした。 TCP/IPの理論的な話であればスティーブンスを理解して あとは実装としてLinuxのTCPスタックを調査すればよいとおもいます。 輻輳だとかパケットロスが実際にあるのは環境によって大小で、 防ぎようがありません。 ちなみに、ストライピングを行えばスロースタートの影響は小さくできます。 GridFTP等の文献をあたればその辺の記述が見つかるでしょう。 ただし、増やしすぎるとそれもそれで問題になります。 私が知りたかったのは、BDPの何倍くらいの値を取ればよいのか、 その決定方法が具体的にあるかが知りたかったのですが、 エンド依存の面もあるということがわかっただけで十分です。 | ||||||||||||
|
投稿日時: 2008-07-18 15:54
ちなみに、クライアントからサーバまで1Gbpsの線でつながっているといっても、
その間のルータやFWなどがあれば当然遅くなります。 その環境下で、1Gbpsという値の何％まで使えるのかというのは知っておいたほうがいいです。 さすがに実験する以外に知るすべはありません。 私の環境では、Iperfとサーバ側のチューニングによって92%位までは出せましたが、 それ以上にするならkernelの中をいじる必要があるでしょうね。 ゼロコピーが効果的に行われるようにするとか。 この話題の本質からは外れますが・・・ | ||||||||||||
|
投稿日時: 2008-07-18 16:03
後もうひとつ、
＞受信側バッファを一杯にしておくようなことなど無いと思います。 ＞速度を測るだけですからバッファに用は無く、廃棄すればいいだけですから。 Iperfのソースをご覧になれば一目瞭然ですが、 受信したデータはread（実装はrecvを使用して、flagに0をセットしている）しています。 何らかの方法でreadしないとkernelのバッファが消費されずに たまる一方で、広告windowは0のままになってしまいますよ。 | ||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。