OpenFlow性能測定 (第３弾)

前回に引き続き OpenFlow の性能測定をしました。機器の接続構成は前回同様ですが OpenFlow コントローラと OpenFlow スイッチをより性能の高いPCで動かしています。前回 100Mイーサ間のTCPが 5～6Mbits/sec というひどさだったのでどこが悪かったのかを探るためにやってみました。

やってみた結果、前回と今回でいえることは、「できるだけ Packet In/Out はさせるな、さもないとOpenFlow コントローラの性能が足かせになって通信性能が落ちるぞ」、ということでしょうか。当たり前と言えば当たり前ですが数値でみるとはっきりしますね。

■テスト時の環境
各テスト時のハードウェアの構成は以下の通りです。
(1) テスト１
  OpenFlow コントローラ: Trema 0.3.12
    CPU: Intel Core2 Duo E8300 (2.83GHz)
    LAN: 1000Base-T
  OpenFlow スイッチ: Open vSwitch 1.4.0
    CPU: Intel Core2 Duo E8400 (3GHz)
    LAN: 1000Base-T

  コントローラとスイッチ間をギガビットイーサで直結しています。

(2) テスト2
  テスト1 と同じマシンを用いていますがコントローラとスイッチの間を 100Base-TX で接続しています。コントローラとスイッチ間の通信性能が与える影響を見たくてやってみました。

  OpenFlow コントローラ: Trema 0.3.12
    CPU: Intel Core2 Duo E8300 (2.83GHz)
    LAN: 100Base-TX (USB 2.0 の LAN アダプタを使用)
  OpenFlow スイッチ: Open vSwitch 1.4.0
    CPU: Intel Core2 Duo E8400 (3GHz)
    LAN: 1000Base-T のポートだが相手側に合わせて 100Base-TX で動作

(3) テスト3
  テスト2 に対してスイッチをスペックダウンしています。
　前回のテストで用いたスイッチであり、前回テスト時とは単にコントローラを変えた構成です。

  OpenFlow コントローラ: Trema 0.3.12
    CPU: Intel Core2 Duo E8300 (2.83GHz)
    LAN: 100Base-TX (USB 2.0 の LAN アダプタを使用)
  OpenFlow スイッチ: Open vSwitch 1.4.0
    CPU: Intel Core 2 Duo U7500 (1.06GHz)
    LAN: 100Base-TX

OSは、すべて Lubuntu 12.04 Desktop (i386) を使っています。
OpenFlow スイッチ側の OpenFlow ポートは USB 2.0 の LAN アダプタにて 100Base-TX で通信しています。
前回同様に、host1 側で iperf のサーバを動かして、host2 側で実行結果を採取しています。

■テスト時の OpenFlow フレームワーク Trema の定義
前回で用いた、すべてのパケットがOpenFlowコントローラを経由する定義です。

class SimpleHubPacketInOut < Controller
  def packet_in( datapath_id, message )
    send_packet_out(
      datapath_id,
      :packet_in => message,
      :actions => ActionOutput.new( OFPP_FLOOD )
    )
  end
end

OpenFlow 1.0 ではフローエントリに一致しないすべてのパケットがコントローラに送られる仕様なのでフローエントリは登録せずに空のままにしておき packet_in のハンドラだけ定義しています。

■テスト1の結果

TCP も含めて良好な結果がでました。
(1) Ping

$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=1.81 ms
64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=1.19 ms
64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=1.18 ms
64 bytes from 192.168.0.1: icmp_req=4 ttl=64 time=1.19 ms
^C
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 1.181/1.346/1.812/0.272 ms

(2) TCP

$ iperf -c 192.168.0.1
------------------------------------------------------------
Client connecting to 192.168.0.1, TCP port 5001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.2 port 46517 connected with 192.168.0.1 port 5001
[ ID] Interval      Transfer   Bandwidth
[  3]  0.0-10.0 sec   112 MBytes  94.1 Mbits/sec

(3) UDP

$ iperf -c 192.168.0.1 -u -b 100M
------------------------------------------------------------
Client connecting to 192.168.0.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.2 port 36276 connected with 192.168.0.1 port 5001
[ ID] Interval      Transfer   Bandwidth
[  3]  0.0-10.0 sec   114 MBytes  95.7 Mbits/sec
[  3] Sent 81409 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec   114 MBytes  95.3 Mbits/sec   0.063 ms    0/81408 (0%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

■テスト2の結果

テスト１よりは悪いですがそれほど悪化はしていません。
(1) Ping

$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=1.82 ms
64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=1.67 ms
64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=1.83 ms
^C
--- 192.168.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 1.679/1.779/1.832/0.078 ms

(2) TCP

$ iperf -c 192.168.0.1
------------------------------------------------------------
Client connecting to 192.168.0.1, TCP port 5001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.2 port 46521 connected with 192.168.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  96.0 MBytes  80.5 Mbits/sec

(3) UDP

$ iperf -c 192.168.0.1 -u -b 100M
------------------------------------------------------------
Client connecting to 192.168.0.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.2 port 47946 connected with 192.168.0.1 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   114 MBytes  95.7 Mbits/sec
[  3] Sent 81410 datagrams
[  3] Server Report:
[  3]  0.0-10.1 sec   106 MBytes  88.1 Mbits/sec   0.057 ms 5729/81409 (7%)
[  3]  0.0-10.1 sec  1 datagrams received out-of-order

■テスト3の結果
(1) Ping

$ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=1.91 ms
64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=1.81 ms
64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=1.81 ms
64 bytes from 192.168.0.1: icmp_req=4 ttl=64 time=1.93 ms
^C
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 1.811/1.870/1.932/0.063 ms

(2) TCP

$ iperf -c 192.168.0.1
------------------------------------------------------------
Client connecting to 192.168.0.1, TCP port 5001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.2 port 55911 connected with 192.168.0.1 port 5001
[ ID] Interval	     Transfer	  Bandwidth
[  3]  0.0-10.0 sec  83.8 MBytes  70.2 Mbits/sec

(3) UDP

$ iperf -c 192.168.0.1 -u -b 100M
------------------------------------------------------------
Client connecting to 192.168.0.1, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  160 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.2 port 40001 connected with 192.168.0.1 port 5001
[ ID] Interval	     Transfer	  Bandwidth
[  3]  0.0-10.0 sec   114 MBytes  95.8 Mbits/sec
[  3] Sent 81449 datagrams
[  3] Server Report:
[  3]  0.0-10.1 sec   106 MBytes  88.1 Mbits/sec   0.036 ms 5790/81448 (7.1%)
[  3]  0.0-10.1 sec  1 datagrams received out-of-order

前回テスト時は TCP が 5～6Mbits/sec とかなり低い数値でしたが大幅に改善されて 70Mbits/sec となっています。前回テスト時の OpenFlow コントローラは CPU が Core2 Duo SU9300 (1.2GHz)でしたのでコントローラのハード性能アップがかなり影響するということになります。

■ご参考: CPU情報
・Intel Core2 Duo E8400
仕様: http://ark.intel.com/ja/products/33910/Intel-Core2-Duo-Processor-E8400-6M-Cache-3_00-GHz-1333-MHz-FSB
ベンチマーク: http://cpubenchmark.net/cpu.php?cpu=Intel+Core2+Duo+E8400+%40+3.00GHz&id=955
・Intel Core2 Duo E8300
仕様: http://ark.intel.com/ja/products/35070/Intel-Core2-Duo-Processor-E8300-6M-Cache-2_83-GHz-1333-MHz-FSB
ベンチマーク: http://cpubenchmark.net/cpu.php?cpu=Intel+Core2+Duo+E8300+%40+2.83GHz&id=952
・Intel Core2 Duo U7500
仕様: http://ark.intel.com/ja/products/29763/Intel-Core2-Duo-Processor-U7500-2M-Cache-1_06-GHz-533-MHz-FSB-Socket-P
ベンチマーク: http://cpubenchmark.net/cpu.php?cpu=Intel+Core2+Duo+U7500+%40+1.06GHz&id=1015
・Intel Core2 Duo SU9300
仕様: http://ark.intel.com/ja/products/36695/Intel-Core2-Duo-Processor-SU9300-3M-Cache-1_20-GHz-800-MHz-FSB
ベンチマーク: http://cpubenchmark.net/cpu.php?cpu=Intel+Core2+Duo+U9300+%40+1.20GHz&id=1018