web-dev-qa-db-ja.com

300Mビット（14％）での極端なUDPパケット損失、ただしTCP> 800Mビット（再送信なし）

私はiperf3クライアントとして使用するLinuxボックスを持っています。BroadcomBCM5721、1Gbアダプター（2つのポートですが、テストに1つだけ使用）を備えた2つの同じ装備のWindows 2012 R2サーバーボックスをテストしています。すべてのマシンは単一の1Gbスイッチを介して接続されます。

でのUDPのテスト300Mbit

iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192

送信されたすべてのパケットの14％が失われます（まったく同じハードウェアを備えた他のサーバーボックスの場合、古いNICドライバ、損失は約2％））が、50Mビットでも損失が発生します。それほど深刻ではありませんが、TCP同等の設定を使用したパフォーマンス：

iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192

報告された再送信なしで、800Mビットの北の送信速度を生成します。

サーバーは常に次のオプションを使用して起動されます。

iperf3 -sB192.168.30.161

誰のせい？

  1. Linuxクライアントボックス（ハードウェア？ドライバー？設定？）？編集： Windowsサーバーボックス間でテストを実行したところ、300MビットでのUDPパケット損失はさらに高く、22％でした。
  2. Windowsサーバーボックス（ハードウェア？ドライバー？設定？）？
  3. すべてのテストマシンを接続する（単一の）スイッチ？
  4. ケーブル？

編集：

現在、別の方向を試しました：Windows-> Linux。結果：パケット損失は常に、スループットは最大で最大になります

  • -l8192の840Mビット、つまり断片化されたIPパケット
  • -l1472の250Mビット、断片化されていないIPパケット

フロー制御はスループットを制限し、パケット損失を防ぐと思います。特に後者の場合、断片化されていない数値はTCPスループット（断片化されていないTCPは断片化されたTCPと同様の数値になります）に近くありません）ですが、Linuxに比べて非常に大きな改善です->パケット損失の観点から見たWindows。

そしてどのように見つけるか？

サーバーのドライバー設定に関する通常のアドバイスに従ってパフォーマンスを最大化し、有効化/無効化/最大化/最小化/変更を試みました

  • 割り込みモデレート
  • フロー制御
  • 受信バッファー
  • RSS
  • ウェイクオンLAN

すべてのオフロード機能が有効になります。

編集有効化/無効化も試みました

  • イーサネット@ワイヤスピード
  • さまざまなオフロード機能
  • 優先度とVLAN

同様の損失率。

UDP実行の完全な出力：

$ iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192
iperf 3.0.7
Linux mybox 3.16.0-4-AMD64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux
Time: Wed, 13 May 2015 13:10:39 GMT
Connecting to Host 192.168.30.161, port 5201   
      Cookie: mybox.1431522639.098587.3451f174
[  4] local 192.168.30.202 port 50851 connected to 192.168.30.161 port 5201
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 5 second test
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec  33.3 MBytes   279 Mbits/sec  4262
[  4]   1.00-2.00   sec  35.8 MBytes   300 Mbits/sec  4577
[  4]   2.00-3.00   sec  35.8 MBytes   300 Mbits/sec  4578
[  4]   3.00-4.00   sec  35.8 MBytes   300 Mbits/sec  4578
[  4]   4.00-5.00   sec  35.8 MBytes   300 Mbits/sec  4577
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-5.00   sec   176 MBytes   296 Mbits/sec  0.053 ms  3216/22571 (14%)
[  4] Sent 22571 datagrams
CPU Utilization: local/sender 4.7% (0.4%u/4.3%s), remote/receiver 1.7% (0.8%u/0.9%s)

Server output:
-----------------------------------------------------------
Accepted connection from 192.168.30.202, port 44770
[  5] local 192.168.30.161 port 5201 connected to 192.168.30.202 port 50851
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.01   sec  27.2 MBytes   226 Mbits/sec  0.043 ms  781/4261 (18%)
[  5]   1.01-2.01   sec  30.0 MBytes   252 Mbits/sec  0.058 ms  734/4577 (16%)
[  5]   2.01-3.01   sec  29.0 MBytes   243 Mbits/sec  0.045 ms  870/4578 (19%)
[  5]   3.01-4.01   sec  32.1 MBytes   269 Mbits/sec  0.037 ms  469/4579 (10%)
[  5]   4.01-5.01   sec  32.9 MBytes   276 Mbits/sec  0.053 ms  362/4576 (7.9%)

TCP実行：

$ iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192
iperf 3.0.7
Linux mybox 3.16.0-4-AMD64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux
Time: Wed, 13 May 2015 13:13:53 GMT
Connecting to Host 192.168.30.161, port 5201   
      Cookie: mybox.1431522833.505583.4078fcc1
      TCP MSS: 1448 (default)
[  4] local 192.168.30.202 port 44782 connected to 192.168.30.161 port 5201
Starting Test: protocol: TCP, 1 streams, 8192 byte blocks, omitting 0 seconds, 5 second test
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   109 MBytes   910 Mbits/sec    0   91.9 KBytes       
[  4]   1.00-2.00   sec  97.3 MBytes   816 Mbits/sec    0   91.9 KBytes       
[  4]   2.00-3.00   sec  97.5 MBytes   818 Mbits/sec    0   91.9 KBytes       
[  4]   3.00-4.00   sec  98.0 MBytes   822 Mbits/sec    0   91.9 KBytes       
[  4]   4.00-5.00   sec  97.6 MBytes   819 Mbits/sec    0   91.9 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-5.00   sec   499 MBytes   837 Mbits/sec    0             sender
[  4]   0.00-5.00   sec   498 MBytes   836 Mbits/sec                  receiver
CPU Utilization: local/sender 3.5% (0.5%u/3.0%s), remote/receiver 4.5% (2.0%u/2.5%s)

Server output:
-----------------------------------------------------------
Accepted connection from 192.168.30.202, port 44781
[  5] local 192.168.30.161 port 5201 connected to 192.168.30.202 port 44782
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec   105 MBytes   878 Mbits/sec                  
[  5]   1.00-2.00   sec  97.5 MBytes   818 Mbits/sec                  
[  5]   2.00-3.00   sec  97.6 MBytes   819 Mbits/sec                  
[  5]   3.00-4.00   sec  97.8 MBytes   820 Mbits/sec                  
[  5]   4.00-5.00   sec  97.7 MBytes   820 Mbits/sec
performancetcpudppacketlossiperf
11
Eugene Beresovsky

問題はない。これは正常で予期される動作です。

パケット損失の理由は、UDPには輻輳制御がないためです。 tcpでは、輻輳制御アルゴリズムが起動すると、スループットを最大化し、損失を最小化するために、送信側に送信を遅くするように指示します。

したがって、これは実際にはUDPの完全に正常な動作です。 UDPは、受信キューが過負荷になっている場合の配信を保証せず、パケットをドロップします。 UDPの送信レートを高くしたい場合は、受信バッファを増やす必要があります。

-lまたは--len iperfオプションでうまくいくはずです。そしておそらくクライアントのターゲット帯域幅設定-b。

-l、--len n [KM]読み取り/書き込みバッファーの長さをnに設定します（デフォルトは8 KB）

8KB ??これは、輻輳制御がない場合の小さな問題です。

例えばサーバー側。

~$ iperf -l 1M -U -s

これは私がLinuxからLinuxに取得するものです

Client connecting to ostore, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 35399 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.10 GBytes   943 Mbits/sec

しかし、デフォルト設定を使用するUDPの場合、私は

~$ iperf -u -c ostore 
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 52898 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
[  3] Sent 893 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.027 ms    0/  893 (0%)

WT？

いくつかの実験の後、長さと帯域幅の目標の両方を設定する必要があることがわかりました。

~$ iperf -u -c ostore -l 8192 -b 1G
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 8192 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 60237 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.12 GBytes   958 Mbits/sec
[  3] Sent 146243 datagrams
[  3] WARNING: did not receive ack of last datagram after 10 tries.

サーバ側：

~$ iperf -s -u -l 5M 
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 5242880 byte datagrams
UDP buffer size:  224 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 36448
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.1 sec  1008 KBytes   819 Kbits/sec   0.018 ms    0/  126 (0%)
[  4] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 60237
[  4]  0.0-10.0 sec  1.12 GBytes   958 Mbits/sec   0.078 ms    0/146242 (0%)
[  4]  0.0-10.0 sec  1 datagrams received out-of-order

小さなバッファでのパケット損失を示すため。正直に言うと、私が期待していたほど極端ではありません。 Linux/Windows間でテストできるiperf3の信頼できるソースはどこにありますか？

~$ iperf -u -c ostore -l 1K -b 1G
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 1024 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 45061 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   674 MBytes   565 Mbits/sec
[  3] Sent 689777 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec   670 MBytes   562 Mbits/sec   0.013 ms 3936/689776 (0.57%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

サーバ側：

~$ iperf -s -u -l 1K 
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1024 byte datagrams
UDP buffer size:  224 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 45061
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec   670 MBytes   562 Mbits/sec   0.013 ms 3936/689776 (0.57%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

iperf3 github page readmeも参照しましたか？

既知の問題点

UDPパフォーマンス：ESnet 100Gテストベッドのiperf3で、UDPレートが高い（10Gbpsを超える）場合、いくつかの問題が発生します。症状は、クライアント側で使用されている-bオプションに関係なく、iperf3の特定の実行でレシーバーが約20％の損失率を報告することです。この問題はiperf3固有ではないようで、CPU上のiperf3プロセスの配置とインバウンドNICとの関係が原因である可能性があります。場合によっては、CPUアフィニティ（-A）オプションを適切に使用することにより、この問題を軽減できます。 （問題＃55）

より遅いNIC=を使用していますが、関連しているのでしょうか。

8
Matt

あなたは最も明白な犯人-アダプター、そしてドライバーを完全に逃しました（異なるバージョンのドライバーを使用すると異なる結果が得られると述べています）。

すべてのオフロード機能をオフにしてみてください。

0
Dani_l