300Mbit (14 %)에서 극단적 인 UDP 패킷 손실, 재전송없이 TCP> 800Mbit

11

iperf3클라이언트 로 사용하는 Linux 상자가 있으며 Broadcom BCM5721, 1Gb 어댑터 (2 포트, 테스트에 1 개만 사용됨)를 사용하여 동일하게 설치된 Windows 2012 R2 서버 상자 2 개를 테스트합니다. 모든 머신은 단일 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. 리눅스 클라이언트 박스 (하드웨어? 드라이버? 설정?) 편집 : 방금 한 Windows 서버 상자에서 다른 서버 상자로 테스트를 실행했으며 300Mbit의 UDP 패킷 손실이 22 %로 훨씬 높았습니다.
  2. Windows 서버 박스 (하드웨어? 드라이버? 설정?)
  3. 모든 시험기를 연결하는 (단일) 스위치?
  4. 케이블?

편집하다:

이제 다른 방향으로 시도했습니다 : Windows-> Linux. 결과 : 패킷 손실은 항상 0 이고 처리량은 최대

  • 840Mbit -l8192, 즉 단편화 된 IP 패킷
  • -l1472조각화되지 않은 IP 패킷의 경우 250Mbit

흐름 제어가 처리량을 제한하고 패킷 손실을 방지한다고 생각합니다. 특히 후자의 조각화되지 않은 숫자는 TCP 처리량에 가깝지 않습니다 (조각화되지 않은 TCP는 조각화 된 TCP와 비슷한 숫자를 생성 함).하지만 패킷 손실 측면에서 Linux-> Windows에 비해 무한히 크게 향상되었습니다.

그리고 어떻게 알아?

서버의 드라이버 설정에 대한 일반적인 조언을 따라 성능을 최대화하고 활성화 / 비활성화 / 최대화 / 최소화 / 변경을 시도했습니다.

  • 인터럽트 중재
  • 흐름 제어
  • 수신 버퍼
  • RSS
  • 웨이크 온랜

모든 오프로드 기능이 활성화되었습니다.

편집 또한 활성화 / 비활성화하려고했습니다.

  • Ethernet @ Wirespeed
  • 다양한 오프로드 기능
  • 우선 순위 및 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
performance  tcp  udp  packetloss  iperf 
— 유진 베레 소프 스키
소스

답변:

8

문제 없습니다. 이것은 정상이며 예상되는 동작입니다.

패킷 손실의 이유는 UDP에 정체 제어가 없기 때문입니다. 혼잡 제어 알고리즘이 시작될 때 tcp에서 처리량을 최대화하고 손실을 최소화하기 위해 전송 끝이 전송 속도를 늦추도록 지시합니다.

따라서 이것은 실제로 UDP에 대한 전적으로 정상적인 동작입니다. 수신 큐에 과부하가 걸리고 패킷이 삭제되면 UDP는 배달을 보장하지 않습니다. UDP의 전송 속도를 높이려면 수신 버퍼를 늘려야합니다.

-l 또는 --len iperf 옵션은 트릭을 수행해야합니다. 클라이언트의 대상 대역폭 설정 -b

-l, --len n [KM] 길이 읽기 / 쓰기 버퍼를 n으로 설정 (기본값 8KB)

8KB ?? 혼잡 제어가 없을 때는 작은 편입니다.

예를 들어 서버 측에서.

~$ iperf -l 1M -U -s

이것이 내가 리눅스에서 리눅스로 얻는 것입니다

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 페이지 추가 정보 도 보셨습니까 ?

알려진 문제

UDP 성능 : ESnet 100G 테스트 베드의 iperf3에서 높은 UDP 속도 (10Gbps 이상)로 일부 문제가 발견되었습니다. 증상은 특정 iperf3 실행에서 수신자가 클라이언트 측에서 사용 된 -b 옵션에 관계없이 약 20 %의 손실률을보고한다는 것입니다. 이 문제는 iperf3에 특정한 것으로 보이지 않으며 CPU에서 iperf3 프로세스를 배치하고 인바운드 NIC와의 관계로 인해 발생할 수 있습니다. 경우에 따라 CPU 선호도 (-A) 옵션을 적절히 사용하면이 문제를 완화 할 수 있습니다. (문제 # 55)

느린 NIC를 사용하고 있지만 관련이 있는지 궁금합니다.

— 매트
소스
예, 패킷 손실에 대해서는 어떻게 발생하는지 알려 드리겠습니다. 답변 업데이트.
— Matt
고마워 매트, 방금 업데이트를 봤어. 내 iperf (Windows 서버와 Linux 클라이언트 모두)는 버전 2.0.5입니다. 무엇 당신이야?
— Eugene Beresovsky
똑같다. 실제로 대상 대역폭을 1G로 설정하면 Bonkas 대역폭 속도가 14756449370562973696 Bytes / sec 및 기타 손상된 출력이 나타납니다. 아마 깨졌을 것 같아요. 여전히 문제는 버퍼라고 생각합니다 ... Windows는 TCP 및 UDP 버퍼링에서 이상한 일을한다는 것을 알고 있습니다.
— Matt
이상한. 나중에 오늘은 좋은 10G 프로덕션 환경에 접근하여 iperf3를 느슨하게 만들 것입니다. 어떻게되는지 보자.
— Eugene Beresovsky
1
-l스위치가 하는 일을 오해하고 있다고 생각합니다 . 버퍼 크기는 설정하지 않습니다. 패킷 크기를 설정합니다. 이것은 iperf3가 한 번에 소켓에 ​​쓰고 한 번에 소켓에서 읽는 데이터의 양입니다. 를 사용하여 소켓 버퍼 크기를 설정할 수 있습니다 -w. 소스를 보면 setsockopt()소켓 버퍼 크기를 이후에 지정한 값으로 설정하도록 호출하는 것을 볼 수 있습니다 -w.
— András Korn
0

가장 명백한 범인 인 어댑터와 드라이버를 완전히 놓쳤습니다 (다른 버전의 드라이버를 사용하면 다른 결과가 나옵니다).

모든 오프로드 기능을 끄십시오.

— 다니엘
소스
도움이되지 않았습니다-질문에 따라 업데이트되었습니다.
— Eugene Beresovsky
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.