iperfを使用してEC2間のネットワーク帯域幅をテストしてみる

ネットワークパフォーマンスを測定するツールである iperf を Amazon EC2 に対して試してみました。iperf2 と iperf3 の違いの説明と実際に Amazon EC2 のネットワークパフォーマンスを測定してみた内容を記載します。

#Amazon EC2

#AWS

yhana

2022.06.16

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

ネットワークパフォーマンスを測定するツールである iperf を利用することで、EC2 インスタンスのネットワーク帯域幅を測定することができるため試してみました。

iperf は過去にも DevelopersIO でブログ化されています。

AWS のナレッジベースでも紹介されています。

iperf について

iperf はネットワークパフォーマンスを測定するためのツールです。

iperf2 と iperf3 があり、両者に互換性はありません。iperf3 はライブラリとして利用されることも目的としてシンプルなコードでゼロから開発されたバージョンです。他にも nuttcpというツールもあり、2022 年 6 月時点の比較は下表の通りとなります。

引用元：Throughput Tool Comparision

iperf2 と iperf3 の主な違いは、マルチスレッド対応と Windows のサポートであり、使い分けについて Throughput Tool Comparision で紹介されています。

Use iperf2 for parallel streams, bidirectional, or MS Windows-based tests

Use nuttcp for high-speed UDP testing

Use iperf3 otherwise. In particular if you want detailed JSON output. Yes, we are a bit biased. :-)

マルチスレッドの利用、双方向のテスト、Windows での利用の場合は iperf2 を使い、high-speed UDP テストでは nuttcp を使い、それ以外は iperf3 が適しているようです（JSON 好きも iperf3）。

マルチスレッドが必要な状況の一つとして CPU バウンドが発生するかどうかがあり、特に 40G/100G NIC のテスト時には注意する必要があります。iperf3 においても複数の CPU コアを利用する設定はできるようですが、iperf2 より複雑な設定になるため、素直に iperf2 を利用したほうがよさそうです。

iperf2 / iperf3

40G/100G NIC のテスト時のチューニングについては次のページで紹介されています。いつか試してみたいですね。

40G/100G Tuning

iperf を試してみる

iperf を試してみます。

今回の検証環境は下図の構成で構築し、東京リージョンの同一サブネット内の EC2 インスタンス間で 1000Mbits/sec のネットワーク帯域幅で通信できるか確認してみます。

EC2 インスタンスは次の条件で構築しています。

AMI
- Amazon Linux 2 AMI 2.0.20220426.0 x86_64 HVM gp2
- ami-0f9a314ce79311c88
インスタンスタイプ
- t3.xlarge

t3.xlarge を選択した理由は、ベースライン帯域幅として 1.024Gbits/sec が確保されているためです。T3 を含む汎用インスタンスのベースライン帯域幅とバースト帯域幅は次のページで確認できます。

General purpose instances - Amazon Elastic Compute Cloud

また、事前の準備として、セキュリティグループにおいて iperf で利用するポートは許可しています。

iperf3 のインストール

テストはシングルスレッドで十分な見込みであり、Windows ではないので、iperf3 を利用することにします。

今回は Amazon Linux 2 の標準リポジトリからインストールします。送信側と受信側の両方に iperf3 をインストールする必要があります。

$ sudo yum install -y iperf3
$ iperf3 -v
iperf 3.1.7
Linux ip-10-0-0-189.ap-northeast-1.compute.internal 4.14.275-207.503.amzn2.x86_64 #1 SMP Wed Apr 13 20:24:50 UTC 2022 x86_64
Optional features available: CPU affinity setting, IPv6 flow label, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing

バージョン確認コマンドでは利用可能なオプションも分かります。

もし、インストールするバージョンを指定したい場合はソースをダウンロードして利用します。ビルド方法は Github のREADME.mdに説明があります。

iperf/README.md at master · esnet/iperf

iperf2 を利用したい場合は EPEL リポジトリからインストールできます。

$ sudo amazon-linux-extras install epel -y
$ yum list | grep iperf
iperf3.x86_64                           3.1.7-2.amzn2.0.2             @amzn2-core
iperf.x86_64                            2.0.13-1.el7                  epel
iperf3.i686                             3.1.7-2.amzn2.0.2             amzn2-core
iperf3-devel.x86_64                     3.1.7-2.amzn2.0.2             amzn2-core

インストールした iperf3 3.1.7 で利用できるオプションです。

$ iperf3 -h
Usage: iperf [-s|-c host] [options]
       iperf [-h|--help] [-v|--version]

Server or Client:
  -p, --port      #         server port to listen on/connect to
  -f, --format    [kmgKMG]  format to report: Kbits, Mbits, KBytes, MBytes
  -i, --interval  #         seconds between periodic bandwidth reports
  -F, --file name           xmit/recv the specified file
  -A, --affinity n/n,m      set CPU affinity
  -B, --bind      <host>    bind to a specific interface
  -V, --verbose             more detailed output
  -J, --json                output in JSON format
  --logfile f               send output to a log file
  --forceflush              force flushing output at every interval
  -d, --debug               emit debugging output
  -v, --version             show version information and quit
  -h, --help                show this message and quit
Server specific:
  -s, --server              run in server mode
  -D, --daemon              run the server as a daemon
  -I, --pidfile file        write PID file
  -1, --one-off             handle one client connection then exit
Client specific:
  -c, --client    <host>    run in client mode, connecting to <host>
  -u, --udp                 use UDP rather than TCP
  -b, --bandwidth #[KMG][/#] target bandwidth in bits/sec (0 for unlimited)
                            (default 1 Mbit/sec for UDP, unlimited for TCP)
                            (optional slash and packet count for burst mode)
  --fq-rate #[KMG]          enable fair-queuing based socket pacing in
                            bits/sec (Linux only)
  -t, --time      #         time in seconds to transmit for (default 10 secs)
  -n, --bytes     #[KMG]    number of bytes to transmit (instead of -t)
  -k, --blockcount #[KMG]   number of blocks (packets) to transmit (instead of -t or -n)
  -l, --len       #[KMG]    length of buffer to read or write
                            (default 128 KB for TCP, dynamic or 1 for UDP)
  --cport         <port>    bind to a specific client port (TCP and UDP, default: ephemeral port)
  -P, --parallel  #         number of parallel client streams to run
  -R, --reverse             run in reverse mode (server sends, client receives)
  -w, --window    #[KMG]    set window size / socket buffer size
  -C, --congestion <algo>   set TCP congestion control algorithm (Linux and FreeBSD only)
  -M, --set-mss   #         set TCP/SCTP maximum segment size (MTU - 40 bytes)
  -N, --no-delay            set TCP/SCTP no delay, disabling Nagle's Algorithm
  -4, --version4            only use IPv4
  -6, --version6            only use IPv6
  -S, --tos N               set the IP 'type of service'
  -L, --flowlabel N         set the IPv6 flow label (only supported on Linux)
  -Z, --zerocopy            use a 'zero copy' method of sending data
  -O, --omit N              omit the first n seconds
  -T, --title str           prefix every output line with this string
  --get-server-output       get results from server
  --udp-counters-64bit      use 64-bit counters in UDP test packets

[KMG] indicates options that support a K/M/G suffix for kilo-, mega-, or giga-

iperf3 homepage at: http://software.es.net/iperf/
Report bugs to:     https://github.com/esnet/iperf

TCP のテスト

EC2 インスタンス間で 1000Mbits/sec の帯域で通信できるか確認してみます。

iperf の設定にはクライアントモードとサーバモードがあり、クライアントモードからサーバモードに対して送信します。まずは、片方の EC2 インスタンスでサーバモードとして実行します。実行後はクライアントからの接続を待ち受けます。

$ iperf3 -s -p 5001 -i 1 -V -1
iperf 3.1.7
Linux ip-10-0-0-131.ap-northeast-1.compute.internal 4.14.275-207.503.amzn2.x86_64 #1 SMP Wed Apr 13 20:24:50 UTC 2022 x86_64
-----------------------------------------------------------
Server listening on 5001
-----------------------------------------------------------

指定したオプションは次の通りです。

オプション	意味
-s, --server	サーバーモードで実行
-p, --port #	ポートを指定
-i, --interval #	定期的に帯域幅を出力する間隔（秒）
-V, --verbose	より詳細な出力
-1, --one-off	1 つのクライアント接続を処理したら終了

次に、もう 1 つの EC2 インスタンスで TCP で接続するクライアントモードとして実行します。iperf3 はデフォルトが TCP になります。帯域幅は 1000Mbits/sec を指定しています。お試しということもあり、10 秒間の送信時間としています。

$ iperf3 -c 10.0.0.131 -p 5001 -b 1000M -t 10 -i 1 -V

指定したオプションと主要なオプションは次の通りです。

オプション	意味
-c, --client	クライアントモードで実行し、に接続
-u, --udp	UDP を指定、デフォルトは TCP
-p, --port #	ポートを指定
-b, --bandwidth #[KMG]	帯域幅（bits/sec）、デフォルトは UDP で 1Mbit/sec、TCP で無制限
-t, --time #	送信時間（秒）
-i, --interval #	定期的に結果を出力する間隔（秒）
-V, --verbose	より詳細な出力

結果を確認してみます。

サーバモードの結果です。指定したIntervalの間隔（1 秒）毎の転送バイト数Transferと帯域幅Bandwidthが出力されています。また、CPU 使用率も確認することができます。

$ iperf3 -s -p 5001 -i 1 -V -1
iperf 3.1.7
Linux ip-10-0-0-131.ap-northeast-1.compute.internal 4.14.275-207.503.amzn2.x86_64 #1 SMP Wed Apr 13 20:24:50 UTC 2022 x86_64
-----------------------------------------------------------
Server listening on 5001
-----------------------------------------------------------
Time: Wed, 15 Jun 2022 14:23:19 GMT
Accepted connection from 10.0.0.189, port 33210
      Cookie: ip-10-0-0-189.ap-northeast-1.compute
      TCP MSS: 0 (default)
[  5] local 10.0.0.131 port 5001 connected to 10.0.0.189 port 33212
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec   109 MBytes   915 Mbits/sec
[  5]   1.00-2.00   sec   119 MBytes  1.00 Gbits/sec
[  5]   2.00-3.00   sec   119 MBytes  1.00 Gbits/sec
[  5]   3.00-4.00   sec   119 MBytes   999 Mbits/sec
[  5]   4.00-5.00   sec   119 MBytes  1.00 Gbits/sec
[  5]   5.00-6.00   sec   119 MBytes   999 Mbits/sec
[  5]   6.00-7.00   sec   119 MBytes  1.00 Gbits/sec
[  5]   7.00-8.00   sec   119 MBytes  1.00 Gbits/sec
[  5]   8.00-9.00   sec   119 MBytes   999 Mbits/sec
[  5]   9.00-10.00  sec   119 MBytes   999 Mbits/sec
[  5]  10.00-10.04  sec  0.00 Bytes  0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-10.04  sec  0.00 Bytes  0.00 bits/sec                  sender
[  5]   0.00-10.04  sec  1.15 GBytes   987 Mbits/sec                  receiver
CPU Utilization: local/receiver 2.0% (0.3%u/1.6%s), remote/sender 0.0% (0.0%u/0.0%s)
rcv_tcp_congestion cubic

次にクライアントモードの結果です。Interval Transfer Bandwidthはサーバモードと同じ項目であり、再送信された TCP セグメントの数を示すRetrと輻輳ウィンドウサイズを示すCwndが出力されています。また、最後には TCP の輻輳制御アルゴリズムも出力されており、CUBIC-TCP を利用していることが分かります。

$ iperf3 -c 10.0.0.131 -p 5001 -b 1000M -t 10 -i 1 -V
iperf 3.1.7
Linux ip-10-0-0-189.ap-northeast-1.compute.internal 4.14.275-207.503.amzn2.x86_64 #1 SMP Wed Apr 13 20:24:50 UTC 2022 x86_64
Control connection MSS 8949
Time: Wed, 15 Jun 2022 14:23:19 GMT
Connecting to host 10.0.0.131, port 5001
      Cookie: ip-10-0-0-189.ap-northeast-1.compute
      TCP MSS: 8949 (default)
[  4] local 10.0.0.189 port 33212 connected to 10.0.0.131 port 5001
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   109 MBytes   915 Mbits/sec    0   1.07 MBytes
[  4]   1.00-2.00   sec   119 MBytes  1.00 Gbits/sec    0   1.24 MBytes
[  4]   2.00-3.00   sec   119 MBytes  1.00 Gbits/sec    0   1.57 MBytes
[  4]   3.00-4.00   sec   119 MBytes   999 Mbits/sec    0   1.73 MBytes
[  4]   4.00-5.00   sec   119 MBytes  1.00 Gbits/sec    0   1.73 MBytes
[  4]   5.00-6.00   sec   119 MBytes   999 Mbits/sec    0   2.01 MBytes
[  4]   6.00-7.00   sec   119 MBytes  1.00 Gbits/sec    0   2.22 MBytes
[  4]   7.00-8.00   sec   119 MBytes  1.00 Gbits/sec    0   2.36 MBytes
[  4]   8.00-9.00   sec   119 MBytes   999 Mbits/sec    0   2.36 MBytes
[  4]   9.00-10.00  sec   119 MBytes   999 Mbits/sec    0   2.47 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  1.15 GBytes   992 Mbits/sec    0             sender
[  4]   0.00-10.00  sec  1.15 GBytes   992 Mbits/sec                  receiver
CPU Utilization: local/sender 3.5% (0.2%u/3.3%s), remote/receiver 2.0% (0.3%u/1.6%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic

iperf Done.

概ね 1000Mbits/sec のネットワーク帯域幅で通信できていることを確認しました。

Retrに関する補足となりますが、再送は輻輳などが原因で TCP セグメントが失われた場合に発生する可能性があります。Github の issue にRetrに関する質問がありました。

what "Retr" field mean . · Issue #343 · esnet/iperf

TCP の輻輳制御アルゴリズムはカーネルパラメータから確認できます。

$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic

UDP のテスト

次に UDP を用いて同様に 1000Mbits/sec の帯域幅で通信できるかテストしてみます。

サーバモードとして実行します。TCP のときと同様としています。

$ iperf3 -s -p 5001 -i 1 -V -1

次に、もう 1 つの EC2 インスタンスでクライアントモードとして実行します。UDP では帯域幅がデフォルトで 1Mbits/sec なので、測定したい帯域幅を指定しています。指定しているオプションの説明は上記の TCP のテストの説明を参照してください。

$ iperf3 -c 10.0.0.131 -u -p 5001 -b 1000M -t 10 -i 1 -V

サーバモードの結果です。指定したIntervalの間隔（1 秒）毎の転送バイト数Transferと帯域幅Bandwidthが出力されています。TCP のテスト時には出力されていなかった、遅延のばらつきを示すJitterと UDP データグラムのロス率を示すLost/Total Datagramsが出力されています。

$ iperf3 -s -p 5001 -i 1 -V -1
iperf 3.1.7
Linux ip-10-0-0-131.ap-northeast-1.compute.internal 4.14.275-207.503.amzn2.x86_64 #1 SMP Wed Apr 13 20:24:50 UTC 2022 x86_64
-----------------------------------------------------------
Server listening on 5001
-----------------------------------------------------------
Time: Wed, 15 Jun 2022 14:28:06 GMT
Accepted connection from 10.0.0.189, port 33214
      Cookie: ip-10-0-0-189.ap-northeast-1.compute
[  5] local 10.0.0.131 port 5001 connected to 10.0.0.189 port 49734
Starting Test: protocol: UDP, 1 streams, 8949 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  96.7 MBytes   811 Mbits/sec  0.008 ms  1515/12842 (12%)
[  5]   1.00-2.00   sec   114 MBytes   956 Mbits/sec  0.021 ms  612/13970 (4.4%)
[  5]   2.00-3.00   sec   115 MBytes   963 Mbits/sec  0.012 ms  516/13969 (3.7%)
[  5]   3.00-4.00   sec   115 MBytes   964 Mbits/sec  0.015 ms  515/13965 (3.7%)
[  5]   4.00-5.00   sec   114 MBytes   957 Mbits/sec  0.016 ms  612/13981 (4.4%)
[  5]   5.00-6.00   sec   108 MBytes   904 Mbits/sec  0.021 ms  1330/13953 (9.5%)
[  5]   6.00-7.00   sec   119 MBytes  1.00 Gbits/sec  0.028 ms  0/13983 (0%)
[  5]   7.00-8.00   sec   112 MBytes   938 Mbits/sec  0.025 ms  912/14014 (6.5%)
[  5]   8.00-9.00   sec   111 MBytes   930 Mbits/sec  0.019 ms  925/13917 (6.6%)
[  5]   9.00-10.00  sec   116 MBytes   970 Mbits/sec  0.020 ms  415/13964 (3%)
[  5]  10.00-10.04  sec  0.00 Bytes  0.00 bits/sec  0.020 ms  0/0 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.04  sec  0.00 Bytes  0.00 bits/sec  0.020 ms  7352/138558 (5.3%)
CPU Utilization: local/receiver 3.7% (0.8%u/3.0%s), remote/sender 0.0% (0.0%u/0.0%s)

音声通話やビデオ通話などが用途の場合はJitterが品質に影響するため、品質向上に向けた参考にできます。

また、Lost/Total Datagramsのロス率が高い場合は輻輳やバッファ溢れなどが原因の可能性があります。上の結果では全体で 5.3% のデータグラムのロスが発生しているため後で対策します。

次にクライアントモードの結果です。Interval Transfer Bandwidthはサーバモードと同じ項目であり、送信した UDP データグラム数を示すTotal Datagramsも出力されています。

$ iperf3 -c 10.0.0.131 -u -p 5001 -b 1000M -t 10 -i 1 -V
iperf 3.1.7
Linux ip-10-0-0-189.ap-northeast-1.compute.internal 4.14.275-207.503.amzn2.x86_64 #1 SMP Wed Apr 13 20:24:50 UTC 2022 x86_64
Control connection MSS 8949
Setting UDP block size to 8949
Time: Wed, 15 Jun 2022 14:28:06 GMT
Connecting to host 10.0.0.131, port 5001
      Cookie: ip-10-0-0-189.ap-northeast-1.compute
[  4] local 10.0.0.189 port 49734 connected to 10.0.0.131 port 5001
Starting Test: protocol: UDP, 1 streams, 8949 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec   110 MBytes   919 Mbits/sec  12842
[  4]   1.00-2.00   sec   119 MBytes  1.00 Gbits/sec  13970
[  4]   2.00-3.00   sec   119 MBytes  1.00 Gbits/sec  13969
[  4]   3.00-4.00   sec   119 MBytes  1000 Mbits/sec  13965
[  4]   4.00-5.00   sec   119 MBytes  1.00 Gbits/sec  13981
[  4]   5.00-6.00   sec   119 MBytes   999 Mbits/sec  13953
[  4]   6.00-7.00   sec   119 MBytes  1.00 Gbits/sec  13983
[  4]   7.00-8.00   sec   120 MBytes  1.00 Gbits/sec  14014
[  4]   8.00-9.00   sec   119 MBytes   996 Mbits/sec  13917
[  4]   9.00-10.00  sec   119 MBytes  1000 Mbits/sec  13964
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-10.00  sec  1.15 GBytes   992 Mbits/sec  0.020 ms  7352/138558 (5.3%)
[  4] Sent 138558 datagrams
CPU Utilization: local/sender 8.6% (1.9%u/6.7%s), remote/receiver 3.7% (0.8%u/3.0%s)

iperf Done.

EC2 インスタンス間で 5.3% のロスが発生しています。netstatで確認したところ、UDP の統計でreceive buffer errorsがカウントされているので、バッファが足りていない可能性がありそうです。

$ netstat -su
IcmpMsg:
    InType3: 12
    OutType3: 12
Udp:
    131442 packets received
    12 packets to unknown port received.
    7352 packet receive errors
    248 packets sent
    7352 receive buffer errors
    0 send buffer errors
UdpLite:
IpExt:
    InOctets: 2553951796
    OutOctets: 1995254
    InNoECTPkts: 328072

サーバモードとして実行していた EC2 インスタンスで受信バッファを増やします。

変更前の受信バッファは 208KiB です。

$ sysctl net.core.rmem_default
net.core.rmem_default = 212992
$ sysctl net.core.rmem_max
net.core.rmem_max = 212992

4MiB に変更してみます。

$ sudo sysctl -w net.core.rmem_default=4194304
net.core.rmem_default = 4194304
$ sudo sysctl -w net.core.rmem_max=4194304
net.core.rmem_max = 4194304

改めて上記と同様の UDP テストをしたところ、ロス率を 0.11% に低減できました。

$ iperf3 -s -p 5001 -i 1 -V -1
iperf 3.1.7
Linux ip-10-0-0-131.ap-northeast-1.compute.internal 4.14.275-207.503.amzn2.x86_64 #1 SMP Wed Apr 13 20:24:50 UTC 2022 x86_64
-----------------------------------------------------------
Server listening on 5001
-----------------------------------------------------------
Time: Wed, 15 Jun 2022 14:53:54 GMT
Accepted connection from 10.0.0.189, port 33244
      Cookie: ip-10-0-0-189.ap-northeast-1.compute
[  5] local 10.0.0.131 port 5001 connected to 10.0.0.189 port 48851
Starting Test: protocol: UDP, 1 streams, 8949 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec   110 MBytes   920 Mbits/sec  0.012 ms  0/12850 (0%)
[  5]   1.00-2.00   sec   119 MBytes  1.00 Gbits/sec  0.013 ms  0/13971 (0%)
[  5]   2.00-3.00   sec   119 MBytes  1.00 Gbits/sec  0.018 ms  0/13969 (0%)
[  5]   3.00-4.00   sec   119 MBytes   995 Mbits/sec  0.018 ms  68/13972 (0.49%)
[  5]   4.00-5.00   sec   119 MBytes   999 Mbits/sec  0.003 ms  0/13959 (0%)
[  5]   5.00-6.00   sec   119 MBytes   994 Mbits/sec  0.010 ms  84/13970 (0.6%)
[  5]   6.00-7.00   sec   119 MBytes  1.00 Gbits/sec  0.013 ms  0/13974 (0%)
[  5]   7.00-8.00   sec   120 MBytes  1.00 Gbits/sec  0.009 ms  0/14020 (0%)
[  5]   8.00-9.00   sec   119 MBytes   995 Mbits/sec  0.017 ms  0/13905 (0%)
[  5]   9.00-10.00  sec   119 MBytes  1000 Mbits/sec  0.012 ms  0/13965 (0%)
[  5]  10.00-10.04  sec  0.00 Bytes  0.00 bits/sec  0.012 ms  0/0 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-10.04  sec  0.00 Bytes  0.00 bits/sec  0.012 ms  152/138555 (0.11%)
CPU Utilization: local/receiver 8.5% (1.6%u/7.0%s), remote/sender 0.0% (0.0%u/0.0%s)

UDP でも概ね 1000Mbits/sec の帯域幅で通信できていることを確認しました。

お役立ち情報

iperf を利用する上で役に立つページや情報をまとめました。このブログを書くときに気になったことや調べたことを書いているだけなので、情報にまとまりはないです。

EC2 のネットワークパフォーマンスに影響を与える要因

VPC 内にある EC2 インスタンスのネットワークパフォーマンスに影響を与える要因には次の内容があり、AWS のブログで紹介されています。こうしてまとめてくれているのはとても助かりますね。

EC2 インスタンスの物理的な近接性
EC2 インスタンスの最大送信単位 (MTU)
EC2 インスタンスのサイズ
Linux に対する Amazon EC2 の拡張ネットワークサポート
配置グループを使用した Amazon EC2 高性能コンピューティング (HPC) のサポート
EC2 インスタンスのネットワーク I/O クレジットメカニズム

iperf2 の情報入手先

Iperf のサイトです。ダウンロードページやソースコードもここにあります。TicketsやDiscussionタブから情報を得ることもできます。

IPerf2 download | SourceForge.net

ユーザーマニュアルです。今回のブログでは iperf2 は試しませんでしたが、オプションが iperf3 と異なっている点があるなど注意が必要です。

Manpage of IPERF

使い方の Youtube 動画もありました。

Robert McMahon - YouTube

iperf3 の情報入手先

リリース情報は次のページです。

iperf3 — iperf3 3.10.1 documentation

Github のリポジトリです。

esnet/iperf: iperf3: A TCP, UDP, and SCTP network bandwidth measurement tool

既知の問題については次のページに掲載されています。

iperf3 Development — iperf3 3.10.1 documentation

FAQ です。参考になります。

iperf3 FAQ — iperf3 3.10.1 documentation

FAQ の最後にありますが、iperf3 の情報をさらに得たい場合として次の方法が紹介されています。

Stack Overflow で質問する、または、質問を確認する
メーリングリストに参加する
- 参加方法は iperf3 Development — iperf3 3.10.1 documentation
Github のプルリクエストなどを確認する
- esnet/iperf: iperf3: A TCP, UDP, and SCTP network bandwidth measurement tool

Amazon Linux 2 のネットワークチューニング関連の設定確認

TCP の複製制御アルゴリズムの確認方法

Amazon Linux 2 では、次のコマンドで利用しているアルゴリズムのカーネルパラメータを確認できます。

$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic

利用できるアルゴリズムは次のコマンドで確認できます。CUBIC-TCP の他に Reno がありました。

$ sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = cubic reno

送受信バッファの確認方法

Amazon Linux 2 では、次のコマンドで送受信バッファのデフォルト値を確認できます。

$ sysctl net.core.rmem_default
net.core.rmem_default = 212992
$ sysctl net.core.wmem_default
net.core.wmem_default = 212992

最大値は次のコマンドです。

$ sysctl net.core.rmem_max
net.core.rmem_max = 212992
$ sysctl net.core.wmem_max
net.core.wmem_max = 212992

さいごに

ネットワークパフォーマンスを測定するツールである iperf を利用して、EC2 インスタンス間のネットワーク帯域幅を確認してみました。他の用途として、Direct Connect や VPN を利用している環境において、オンプレミスから AWS へのネットワーク帯域幅の確認にも利用することができます。冒頭でも紹介している次のブログは VPN の帯域の問題のトラブルシューティングに役立ちます。