 メイン Statistics: Understanding Your Simulation Results
アプリケーション層とTCP層のスループットの不一致について | 投稿するにはまず登録を |
| スレッド表示 | 新しいものから | 前のトピック | 次のトピック | 下へ |
| 投稿者 | スレッド |
|---|---|
| ichiko | 投稿日時: 2008/10/11 13:43 |
新米   登録日: 2008/3/4 居住地: 投稿: 17 |
アプリケーション層とTCP層のスループットの不一致について こんにちは.
この度，出力されたTCP層のデータから予測されるスループットとFTP/GENERICのスループットが大きくかけ離れているので投稿させていただきました. シナリオは2台のノードがAPにFTP/GENERIC（1パケット1500bytes）をそれぞれ送信しているという環境です.TCPの設定はオプション（遅延ACKなど）はつけず，MSS（Maximum segment size）は1500bytes，受信バッファ，送信バッファともに65000bytesとしています. 物理層でのBERは0としています. configファイル，シナリオファイルは添付させていただきました. statファイルから，ノードが受信した重複ACKは0個であり，データ再送がないことがわかります.例えば，ノード2のスループットは約， 引用： ノード2が受信したACK数×1セグメント（1500bytes）/シミュレーション時間 となるはずです.ですが，FTP/GENERICで見たスループットはその1/3ほどになっています.これはなぜなんでしょうか？ APを受信サーバにしているため，バッファがボトルネックになっているかと思い，APのバッファを1000000bytesにしたのですが，結果は変わりません. ノード同士の距離を広げて隠れ端末関係にしますと，このような不一致はおきず，TCP層のデータからの計算とほぼ一致します. ご教授お願い致します.  TCP.zip |
| hiro | 投稿日時: 2008/10/12 14:48 |
長老  登録日: 2005/7/16 居住地: 投稿: 452 |
Re: アプリケーション層とTCP層のスループットの不一致について 添付のシナリオを実行してみましたが、全く異なる結果になりました。
例えば、 添付されたzipにある、error1.statとこちらで実行したQualnet.statを比較すると。 以下のようになります。 引用：
全然パケットが届かないです。 それから、 > 物理層でのBERは0としています. とは、具体的にどうしていますか。 また、 > ノード同士の距離を広げて隠れ端末関係にしますと，このような不一致はおきず，TCP層のデータからの計算とほぼ一致します. ということであれば、何の影響なのか調べやすい気がしますが。 |
| ichiko | 投稿日時: 2008/10/14 13:33 |
新米 登録日: 2008/3/4 居住地: 投稿: 17 |
Re: アプリケーション層とTCP層のスループットの不一致について hiroさん，ありがとうございます．
>全然パケットが届かないです。 >それから、 >> 物理層でのBERは0としています. >とは、具体的にどうしていますか。 /wireless/src/phy802_11.cppのL205あたりの を 私もBERをデフォルトのままでシミュレーションしますとほとんどパケットが届かなかったです． >また、 >> ノード同士の距離を広げて隠れ端末関係にしますと，このような不一致はおきず，TCP層のデータからの計算とほぼ一致します. >ということであれば、何の影響なのか調べやすい気がしますが。 これは隠れ端末関係になるとMAC層でのフレームの衝突が増えるだけなのでTCPより上のレイヤには直接影響を与えないと思います． なのでQualNetのバグなのではないかと考えているのですが，どうでしょうか？ |
| ipoten | 投稿日時: 2008/10/15 22:59 |
一人前  登録日: 2005/7/12 居住地: 投稿: 102 |
Re: アプリケーション層とTCP層のスループットの不一致について こんにちは
単にMACのCSMAの遅延を反映しているのではないでしょうか。 == ノード2と3が隠れ端末でない場合 == お互いにキャリアセンス可能のため、 バックオフによるアクセス遅延が発生。 これがFTPのスループット低下に反映される。 (ただしMACで衝突による再送はなし) == ノード2と3が隠れ端末関係にある場合 == お互いにキャリアセンスできないため、 アクセス遅延なしでバシバシ投げる。 タイミング的には衝突しているが、BER=0なので全部受かる。 結果的に最大スループットが出る。 ここまではつじつまはあっていると思います。 問題は、ichikoさんの計算するTCPのスループットが どちらのケースでも高く出ているということ。 このシナリオではFTP/GENERICのアイテムサイズが1500byteとなっていますが、 例えばなにか余分なヘッダがついたりして、 TCPでは1500byteと余分byteのセグメントを交互に 送っていたりするということはありませんかね。 試しに巨大なファイル1個をアップロードするような設定にしても 同様の現象が発生するでしょうか？ (例えば、1.5GBのデータをTCPで1500byte×100万セグメント送信する。 FTPのセッション時間で割れば、同様のスループットが算出できると思います。) |
| ichiko | 投稿日時: 2008/10/17 15:41 |
新米 登録日: 2008/3/4 居住地: 投稿: 17 |
Re: アプリケーション層とTCP層のスループットの不一致について ipotenさんありがとうございます．
<例えばなにか余分なヘッダがついたりして、 <TCPでは1500byteと余分byteのセグメントを交互に <送っていたりするということはありませんかね。 1500byte以外にやりとりしているものはTCP-ACKしかありませんが，これはデータではないので上記のデータ数には入らないと思われます． <試しに巨大なファイル1個をアップロードするような設定にしても <同様の現象が発生するでしょうか？ <(例えば、1.5GBのデータをTCPで1500byte×100万セグメント送信する。 ipotenさんの言うとおりに一つの端末がAPに1.5GBのデータをTCPで1500byte×100万セグメント送信する環境でシミュレーションしてみました．（シナリオ，コンフィグファイルは添付しています） これより，アプリケーションレイヤでの受信データ数は1000000に対し，TCPレイヤでの受信データ数は1178257でした．これはstatファイルのTCP Data Packets Receivedを見ています．（送信側のTCP Data Packets in Sequenceは1180775より若干差があるが）間違っているかもしれませんが，受信側を見ているので再送数は気にする必要はないと思います． そこで生じる疑問はなぜアプリケーションでの受信データ数よりTCPレイヤでの受信データ数の方が多いかです．これには他にどのようなことが考えられでしょうか？ TCP2.zip |
| ipoten | 投稿日時: 2008/10/21 23:27 |
一人前 登録日: 2005/7/12 居住地: 投稿: 102 |
Re: アプリケーション層とTCP層のスループットの不一致について こんにちは
引用： <試しに巨大なファイル1個をアップロードするような設定にしても そのサイズを1.5GBにするというものです。 これによりTCPが1500byteごとに分割して100万セグメントを送信しようとします。 以下は、私の意図したFTP-GENの設定例です。 ichikoさんの行った1500byte×100万アイテムの送信のときの1178257よりは、 想定に近い値になりました。 # 1.5GBは大きすぎましたね。1.5MBでも十分確認できた。 引用： これより，アプリケーションレイヤでの受信データ数は1000000に対し，TCPレイヤで 「データ数」100万個というのは統計値からは読み取れないですよね。 つまり、1.5GBのアプリケーションデータが、実際にいくつのTCPセグメントに分割送信されたのかは不明です。 上記2ケースを比較すると、私が前回疑ったように、アプリケーションからTCPにデータを渡す際に、 何か余分なヘッダをつけているか、または別のデータを送信しているのではないかと推測するわけです。 もしかしてFTPの制御セッションか何かじゃないですかね。 このあたりを確認されてはいかがでしょうか？ |
| ichiko | 投稿日時: 2008/10/28 17:27 |
新米 登録日: 2008/3/4 居住地: 投稿: 17 |
Re: アプリケーション層とTCP層のスループットの不一致について ipotenさんありがとうございます。
引用： 上記2ケースを比較すると、私が前回疑ったように、アプリケーションからTCPにデータを渡す際に、 何か余分なヘッダをつけているか、または別のデータを送信しているのではないかと推測するわけです。 もしかしてFTPの制御セッションか何かじゃないですかね。 このあたりを確認されてはいかがでしょうか？ そうですね〜 ipotenさんがしてくださった検証より、FTPからTCPに別の制御データを渡している可能性は大きいかもしれませんね。これからFTP/GENERICのコードをしばらく勉強することにします。ありがとうございました。 |
| スレッド表示 | 新しいものから | 前のトピック | 次のトピック | トップ |
