オルタナティブ・ブログ > プログラマー社長のブログ >

プログラミングでメシが食えるか!?

Ethdelayのパケット入れ替え機能を実測してみた

»

マニアネタが続いてすみません。昨日実装した回線遅延シミュレータ:Ethdelayのパケット入れ替えシミュレーションを、実際にパケットを通過させて測定してみました。

どうやって測定しようかと考えたのですが、結局測定専用のUDPプログラムを作りました。送信側はジャンジャンUDPパケットを送り続け、受信側は最初に受けたパケットの時刻を記憶し、それ以降到着したパケットの遅延具合を計測する感じのプログラムです。スループット測定プログラムを作るようなものですが、パケットの入れ替え状況を見たいので、アウトプットのみ少し工夫した程度です。

まあ、細かいことはさておき、結果を見てみましょう。送信側はウェイトなしで1400バイトのデータを10万個送信し、受信側でどんな感じに受信できたかを出力し、それをグラフにしました。高性能版のEthdelayProを使って測定しています。

Photo

縦軸が最初のパケットからの遅延時間(秒)です。横軸は送信側で連番をつけたパケット番号です。

一様分布はまあ、目的通り、ばらけて分布しています。正規分布は、分散が小さいとかなり癖が出ています。おそらく内部のバッファ処理と排他の関係で、相対的に処理自体の重さが目立ってしまっているのでしょう。分散が大きくなるにつれてそれらしい範囲に綺麗に分布するようになります。

Ethdelay(アルマジロ版)も測定してみました。こちらはCPU性能も低く、100Mbpsリンクアップなので、100パケット送信しても70パケットくらいしか受信できませんでした。

Ar

分散が小さい時により癖が目立ってしまいます。まあ、実用上は分散を小さくする意味はあまりないと思いますので(WANや無線の実回線だともっとばらつきます)、問題ないでしょう。

ちなみに、もっとパケットがたくさんだとどうなるのかもグラフで紹介しておきましょう。Ethdelay(アルマジロ版)です。

2

送信側ウエイトなしではパケットロスがかなり発生してしまうため(送信側が速すぎる)、ウエイトを1ミリ秒で比較した方がわかりやすいですね。第一受信パケットからの遅延時間のグラフなので、右肩上がりになります。そのばらつき具合が分散になります。分散を大きくしていくとグラフで所々隙間ができたりしていますが、処理が重たくなっているためでしょう。まあ、実回線に近い感じで、適当に揺らぎがある、ということで。。ちなみに、ウエイトを1ミリ秒の状態で、受信側で測定して、スループットは8~9Mbpsくらいです。ウエイト1ミリ秒ですと送信側でも10Mbps程度です。

ちなみに、EthdelayProでは、

3

送信側ウエイトなしでもロスする割合は減り、分散500でウエイト1ミリ秒での変な揺らぎも発生しません。NICもCPUも余裕があるおかげです。が、性能の悪い回線をシミュレーションするという意味ではEthdelayでも十分と言えるでしょう。なお、受信側スループットとしては、送信側ウエイトなしで219Mbps、ウエイト1ミリ秒で9.5Mbpsとなります。

さて、私が作るソースは危険なプログラムが多くてなかなかソースを公開しにくいことが多いのですが、今回のUDP送受信プログラムは簡単ですし、サーバをダウンさせるようなこともできないので、公開しておきます。まあ、このくらいどなたでも簡単に作れると思いますが。gccでコンパイルして使ってください。LinuxやMacなどUNIX系のOSで動くと思います。なんのサポートもしませんので、あしからず。。

UDP送受信プログラム:udptest.cをダウンロード

もう少しまともに整理したものです(2009.11.6):UdpTest.tar.gzをダウンロード

Comment(0)