แพ็คเก็ต UDP สุดขีดสูญเสียที่ 300Mbit (14%) แต่ TCP> 800Mbit โดยไม่มีการส่งสัญญาณซ้ำ


11

ฉันมีกล่อง linux ที่ฉันใช้เป็นiperf3ไคลเอนต์ทดสอบกล่องเซิร์ฟเวอร์ Windows 2012 R2 2 ตัวที่ติดตั้งมาพร้อมกับ Broadcom BCM5721, อะแดปเตอร์ 1Gb (2 พอร์ต แต่ใช้เพียง 1 พอร์ตสำหรับการทดสอบ) เครื่องทั้งหมดเชื่อมต่อกันด้วยสวิตช์ 1Gb เพียงตัวเดียว

ทดสอบ UDP ที่เช่น 300Mbit

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 หนึ่งไปยังกล่องอื่นและการสูญเสียแพ็กเก็ต UDP ที่ 300Mbit ยิ่งสูงขึ้นที่ 22%
  2. กล่องเซิร์ฟเวอร์ windows (การตั้งค่าฮาร์ดแวร์ไดรเวอร์หรือไม่)
  3. สวิตช์ (เดี่ยว) ที่เชื่อมต่อเครื่องทดสอบทั้งหมดหรือไม่
  4. สายเคเบิ้ล?

แก้ไข:

ตอนนี้ฉันลองไปอีกทิศทางหนึ่ง: Windows -> Linux ผลลัพธ์: การสูญเสียแพ็คเก็ตเสมอ 0ในขณะที่ปริมาณงานมากที่สุด

  • 840Mbit สำหรับ-l8192เช่นแพ็คเก็ต IP ที่กระจัดกระจาย
  • 250Mbit สำหรับ-l1472แพ็กเก็ต IP ที่ไม่มีการจัดเรียง

ฉันเดาปริมาณการควบคุมการไหลสูงสุดและป้องกันการสูญเสียแพ็คเก็ต โดยเฉพาะอย่างยิ่งหลังตัวเลขที่ไม่มีการแยกส่วนจะไม่มีที่ไหนใกล้กับปริมาณงาน TCP (TCP ที่ไม่ได้แยกส่วนจะให้ตัวเลขใกล้เคียงกับ TCP ที่แยกส่วน) แต่เป็นการปรับปรุงที่ใหญ่กว่า Linux -> Windows อย่างมากในแง่ของการสูญเสียต

และวิธีการหา?

ฉันทำตามคำแนะนำตามปกติสำหรับการตั้งค่าไดรเวอร์บนเซิร์ฟเวอร์เพื่อเพิ่มประสิทธิภาพและพยายามเปิด / ปิด / เพิ่ม / ลด / เปลี่ยน

  • การขัดจังหวะการกลั่นกรอง
  • ควบคุมการไหล
  • รับบัฟเฟอร์
  • RSS
  • Wake-On-LAN

เปิดใช้งานฟีเจอร์การถ่ายภาพทั้งหมด

แก้ไขฉันพยายามเปิด / ปิดการใช้งานด้วย

  • อีเธอร์เน็ต @ Wirespeed
  • ฟีเจอร์ offload ที่หลากหลาย
  • ลำดับความสำคัญและ 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

เพื่อแสดงการสูญเสียแพ็กเก็ตด้วยบัฟเฟอร์ขนาดเล็ก ซึ่งความซื่อสัตย์ไม่ได้สุดขีดอย่างที่ฉันคาดหวัง iperf3 เป็นแหล่งที่เชื่อถือได้ที่ไหนฉันสามารถทดสอบระหว่าง Linux / Windows

~$ 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: พบปัญหาบางอย่างกับ iperf3 บน ESnet 100G ที่ทดสอบด้วยอัตรา UDP สูง (สูงกว่า 10Gbps) อาการคือเมื่อใดก็ตามที่ iperf3 เรียกใช้ตัวรับรายงานอัตราการสูญเสียประมาณ 20% โดยไม่คำนึงถึงตัวเลือก -b ที่ใช้ในฝั่งไคลเอ็นต์ ปัญหานี้ดูเหมือนจะไม่เฉพาะ iperf3 และอาจเกิดจากการจัดวางกระบวนการ iperf3 บน CPU และความสัมพันธ์กับ NIC ขาเข้า ในบางกรณีปัญหานี้สามารถบรรเทาได้ด้วยการใช้ตัวเลือก CPU affinity (-A) ที่เหมาะสม (ฉบับที่ 55)

คุณกำลังใช้ NIC ที่ช้าลง แต่ฉันสงสัยว่ามันเกี่ยวข้องกันหรือไม่


ใช่และสำหรับการสูญเสียแพ็คเก็ตฉันจะแสดงให้คุณเห็นว่าสิ่งนี้สามารถเกิดขึ้นได้ อัปเดตคำตอบ
แมตต์

ขอบคุณแมตต์เพิ่งเห็นการอัปเดตของคุณ My iperf (ทั้งบนเซิร์ฟเวอร์ Windows และไคลเอนต์ Linux) คือรุ่น 2.0.5 ของคุณคืออะไร
Eugene Beresovsky

เหมือน. และในความเป็นจริงเมื่อฉันตั้งค่าแบนด์วิดท์เป้าหมายเป็น 1G ฉันจะได้รับอัตราแบนด์วิดธ์ bonkas 14756449370562973696 Bytes / วินาทีและเอาท์พุทที่เสียหายอื่น ๆ ดังนั้นฉันคิดว่ามันอาจจะเสีย ยังฉันคิดว่าปัญหาคือบัฟเฟอร์ ... ฉันรู้ว่า windows ทำบางสิ่งผิดปกติกับ TCP และ UDP บัฟเฟอร์
แมตต์

แปลก. ต่อมาวันนี้ฉันอาจจะได้รับการเข้าถึงสภาพแวดล้อมการผลิตที่ดี 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.