Develop and Download Open Source Software

OpenSource Downloads

7-Zip  (4,208)  
HandBrake Japanese Language Version  (3,353)  
CrystalDiskInfo  (1,743)  
CotEditor  (1,120)  
CrystalDiskMark  (866)  
Boookends  (788)  
SMPlayer  (642)  
えこでこツール  (599)  
Tera Term  (595)  
10  FFFTP  (579)  
11  Cabos  (530)  
12  BathyScaphe  (494)  
13  ffdshow  (481)  
14  MergeDoc  (464)  
15  ギコナビ  (438)  
More >>

最近ブックマークされた記事

ネットワークのベンチマーク・ツールを試す - nepim、LMbench、nuttcp

2008年08月22日 11:32 Ben-Martin(2008年8月13日(水)) 1 2 3
 ネットワークのベンチマークでは、伝送速度と遅延時間という2つの指標が特に関心の対象となる。サービスや製品の広告では、伝送速度の方が大きく取り上げられることが多いが、状況によっては遅延時間の方が重要な指標となる場合もある。この記事では、ネットワークのパフォーマンス測定に利用できる3つのツールを見ていくことにしよう。nepim(network pipemeter)、LMbenchnuttcpの3つだ。

 今回のテストでは、64ビットのFedora 9搭載マシンで各ツールをソースからビルドした。使用したバージョンは、nepimが0.51、LMbenchが3、nuttcpが5.5.5だ。

 また今回は、ギガビット・イーサネットのネットワーク・インタフェース・カード2枚をbonding構成翻訳記事)で組み合わせたネットワーク・リンクを使用した。だが、結果を見るとわかるように、何かがうまく機能していなかったようで、2ギガビットという理論上の伝送速度は達成できなかった。後述するnepimとnuttcpのベンチマークでは、サーバからの下りの通信の方が、上りの通信より速かった。これはネットワーク・インタフェースのbondingの効果かもしれない。

nepim

 nepimは、openSUSE 11には1クリック・インストール用のパッケージがあるが、FedoraやUbuntuのリポジトリにはない。また、liboopライブラリもインストールする必要があるが、こちらもopenSUSE用のパッケージはあってFedoraとUbuntu用はない。liboopはソースから「./configure; make; sudo make install」でインストールできる。

 nepimのビルドにはautotoolsは使わない。srcディレクトリに移動し、makeを実行してコンパイルする。私が試したところ、Makefileに定義を追加して、データ構造の定義の重複を回避してからコンパイルする必要があった。変更内容およびインストール方法は次に示すとおりだ(Makefileにはinstallターゲットはない)。

$ cd src
$ vi Makefile
...
ifeq ($(PLATFORM),Linux)
CFLAGS += -DHAVE_STDINT -DHAVE_SUSECONDS_T \
        -DHAVE_SIGHANDLER_T -DHAVE_IP_MREQN -DHAVE_IP_MREQ -DHAVE_INET6_S6_ADDR32 -DHAVE_GROUP_SOURCE_REQ
ifdef ENABLE_DLOPEN
LDFLAGS += -ldl
endif
endif
...
$ make
$ sudo install -m 555 nepim /usr/local/bin

 コマンドライン・オプションを指定せずにnepimを起動すると、サーバ・モードで立ち上がる。サーバ・モードのnepimは、システムの各インタフェースをリッスンし、UDPとTCP接続の両方を受け入れる。一方、-cオプションを指定してnepimを起動すると、クライアント・モードで立ち上がる。接続先のサーバをいくつか指定して、ネットワーク・リンクのベンチマークを開始できる。

 サーバ側でnepimを起動したときの動作の様子と、クライアントが接続してきたときの出力内容を次に示す。先頭が"6 cur"の行はベンチマークの実行中に出力される。最後の3つの行は、クライアントが切断したときに出力されるもので、両方向の通信速度の平均値、最小値、最大値(キロビット/秒単位)と、1秒あたりに送受信したパケット数が示されている。

$ nepim
nepim - network pipemeter - version 0.51
server: tcp_read=32768 tcp_write=32768 udp_read=4096 udp_write=4096
3: TCP socket listening on ::,1234
...
6: TCP incoming: ::ffff:192.168.10.200,38176
6: send=1 bit_rate=-1 pkt_rate=-1 interval=2 duration=10 delay=250000 ....
6: sweep write: floor=32768 ceil=32768
6: pmtud_mode=1 path_mtu=1500 mss=1448 tos=0 ttl=64 mcast_ttl=64 win_recv=87380 win_send=16384 sock_ka=1 nodelay=0

                 kbps_in   kbps_out    rcv/s    snd/s
  6 cur     8  273194.97  676940.88  2619.50  2583.00
  6 cur     6  235308.55  722075.62  2435.50  2754.50
  6 cur     4  223439.58  723386.38  2282.00  2759.50
  6 cur     2  255724.64  702152.69  2346.00  2678.50
  6 avg     0  246072.14  708041.75  2413.30  2701.10
  6 min     0  223439.58  676940.88  2282.00  2583.00
  6 max     0  273194.97  723386.38  2619.50  2759.50
write: errno=104: Connection reset by peer
write: connection lost on TCP socket 6
6: pmtud_mode=1 path_mtu=1500 mss=1448 tos=0 ttl=64 mcast_ttl=64 win_recv=603680 win_send=256360 sock_ka=1 nodelay=0

 デフォルトでは、クライアントがサーバに接続した後のトラフィックは、サーバからクライアントへという一方向のみに流れる。これはオプションで変更可能だ。-sオプションを使うと、クライアントからサーバへ通信が行われ、-dオプションを使うと、両方向で通信が行われる。上記のサーバに接続するクライアント側のセッションの例を次に示す。

$ nepim -c 192.168.10.200 -d
nepim - network pipemeter - version 0.51
client: tcp_read=32768 tcp_write=32768 write_floor=32768 write_ceil=32768 step=1
not a UNIX domain path: 192.168.10.200: errno=2: No such file or directory
...
3: TCP socket connected to 192.168.10.210,1234
3: sending: hello server_send=1 bit_rate=-1 pkt_rate=-1 stat_interval=2 ...
3: greetings sent to 192.168.10.210,1234
3: pmtud_mode=1 path_mtu=1500 mss=1448 tos=0 ttl=64 mcast_ttl=1 win_recv=87380 win_send=16384 sock_ka=1 nodelay=0

                 kbps_in   kbps_out    rcv/s    snd/s
  3 cur     8  675722.31  273269.25  2696.00  1086.00
  3 cur     6  719693.06  235371.25  3278.50   953.50
  3 cur     4  725370.31  223025.72  3067.50   898.50
  3 cur     2  700528.75  255723.53  2785.00  1019.00
  3 avg     0  706910.69  246072.14  2943.30   986.20
  3 min     0  675722.31  223025.72  2696.00   898.50
  3 max     0  725370.31  273269.25  3278.50  1086.00
3: pmtud_mode=1 path_mtu=1500 mss=1448 tos=0 ttl=64 mcast_ttl=1 win_recv=1688544 win_send=99000 sock_ka=1 nodelay=0
nepim: no event sink registered
nepim: done

 nepimサーバの起動時に「-U /tmp/nepim-socket」というオプションを指定すると、TCP/IPネットワークではなくローカル・ドメインのストリーム・ソケットを使って動作する。クライアント側では、-cオプションを使ってローカル・ソケットへのパスを指定し、このソケットに接続してベンチマークを行う。この方法は、ネットワーク・カードによる遅延がない状態でnepimがどの程度の速さで通信できるかを調べたい場合に便利だ。

 次に示すのは、IntelのクアッドコアCPU「Q6600」搭載機のローカル・ドメイン・ソケットでnepimを動作した結果だ。両方向とも約7ギガビットを処理できるという結果になった。このテストの実行中、CPUの使用率は50%強で推移しており、nepimクライアントとサーバのそれぞれがCPUコア1つ分を使っていたことになる。

                 kbps_in   kbps_out    rcv/s    snd/s
  3 cur     8 7100432.50 7105806.50 27203.50 27106.50
  3 cur     6 7268335.50 7266631.50 27887.00 27720.00
  3 cur     4 7105020.00 7108296.50 27196.00 27116.00
  3 cur     2 7189823.50 7188644.00 27557.00 27422.50
  3 avg     0 7154958.50 7156819.50 27413.10 27301.10
  3 min     0 7100432.50 7105806.50 27196.00 27106.50
  3 max     0 7268335.50 7266631.50 27887.00 27720.00

 複数のセッションを同時に張るには、クライアントの起動時に-nオプションで接続数を指定する。ローカル・ソケットのテストで「-n 2」と指定してみたところ、各ストリームは4~4.5ギガビット/秒となり、伝送速度が向上したが、倍にはならなかった。

 nepimクライアントの起動時に-uオプションを指定すると、TCPではなくUDPで通信が行われる。UDPの場合、次に示すように、紛失したパケット数もあわせて出力される。

$ nepim -c 192.168.10.200 -d -u
...
                          kbps_in   kbps_out    rcv/s    snd/s  loss   ooo LOST
  3   0   0  cur     8  595738.62  808632.31 18180.50 24677.50 .0495 .0262 1894
  3   0   0  cur     6  505872.38  868532.25 15438.00 26505.50 .0090 .0050 2174
  3   0   0  cur     4  585842.69  825393.12 17878.50 25189.00 .0177 .0097 2817
  3   0   0  cur     2  563150.88  872955.88 17186.00 26640.50 .0232 .0115 3633
  3   0   0  avg     0  546350.69  866831.56 16673.30 26453.60 .0389 .0190 6749
  3   0   0  min     0  505872.38  808632.31 15438.00 24677.50 .0090 .0050
  3   0   0  max     0  595738.62  872955.88 18180.50 26640.50 .0495 .0262

 nepimは、2つのマシン間の各方向の伝送速度を確認するのに便利だ。送信と受信、および双方向のスループットを調べられるため、1方向でのみ問題が生じているのかどうかを把握できる。また、UDPのテストでは紛失パケット数も示されるので、2台のホスト間にスイッチを配置したことでパケットの紛失が増えたかどうかを確認することも可能だ。

最終更新:2008年10月22日 17:07