300Mbit(14%)での極端なUDPパケット損失、ただし再送信なしのTCP> 800Mbit


11

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

300MbitなどでのUDPのテスト

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

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

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

報告された再送信なしで800Mbitの北の伝送速度をもたらします。

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

iperf3 -sB192.168.30.161

誰のせいですか?

  1. Linuxクライアントボックス(ハードウェア?ドライバー?設定?)? 編集: Windowsサーバーボックス間でテストを実行したところ、300MbitのUDPパケット損失はさらに大きく、22%でした
  2. Windowsサーバーボックス(ハードウェア?ドライバー?設定?)?
  3. すべてのテストマシンを接続する(単一の)スイッチですか?
  4. ケーブル?

編集:

今、私は別の方向を試してみました:Windows-> Linux。結果:パケット損失は常に0ですが、スループットは約で最大になります

  • 840Mbit -l8192、つまりフラグメント化されたIPパケット
  • 250Mbit for -l1472、断片化されていないIPパケット

フロー制御はスループットを制限し、パケット損失を防ぐと思います。特に後者の、断片化されていない数値はTCPスループットに近いところにありません(断片化されていないTCPは断片化されたTCPと同様の数値をもたらします)が、パケット損失の点でLinux-> Windowsをはるかに上回る改善です。

そして、どうやって見つけるのですか?

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

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

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

編集私も有効/無効にしようとしました

  • イーサネット@ワイヤスピード
  • さまざまなオフロード機能
  • Priority&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                  

回答:


8

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

パケット損失の理由は、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ページの readme もご覧になりましたか?

既知の問題点

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

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


ええ、パケット損失については、これがどのように起こるかを示します。回答を更新します。
マット

マットに感謝します、あなたの更新を見ました。私のiperf(WindowsサーバーとLinuxクライアントの両方)はバージョン2.0.5です。君は?
ユージンベレソフスキー

同じ。実際、ターゲット帯域幅を1Gに設定すると、14756449370562973696 Bytes / secおよびその他のこのような破損した出力のボンカ帯域幅レートが得られます。おそらく壊れていると思います。それでも、問題はバッファだと思います... WindowsはTCPとUDPバッファリングで異常なことをします。
マット

奇妙な。本日後日、おそらく私は優れた10G実稼働環境にアクセスできるようになり、その環境でiperf3を解放します。それがどうなるか見てみましょう。
ユージンベレソフスキー

1
-lスイッチの機能を誤解していると思います。バッファサイズは設定しません。パケットサイズを設定します。これは、iperf3が一度にソケットに書き込み、一度にソケットから読み取るデータの量です。を使用してソケットバッファサイズを設定できます-w。ソースを見ると、それが呼び出しsetsockopt()て、ソケットバッファサイズをあとで指定したものに設定することがわかります-w
アンドラスコーン

0

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

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


それは助けにはなりませんでした-質問はそれに応じて更新されました。
ユージンベレソフスキー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.