Mất gói UDP cực lớn ở mức 300Mbit (14%), nhưng TCP> 800Mbit sẽ không truyền lại


11

Tôi có một hộp linux tôi sử dụng làm iperf3máy khách, thử nghiệm 2 hộp máy chủ Windows 2012 R2 được trang bị giống hệt với Broadcom BCM5721, bộ điều hợp 1Gb (2 cổng, nhưng chỉ có 1 được sử dụng cho thử nghiệm). Tất cả các máy được kết nối thông qua một công tắc 1Gb.

Kiểm tra UDP ở mức 300Mbit

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

dẫn đến mất 14% tất cả các gói được gửi (đối với hộp máy chủ khác có phần cứng chính xác, nhưng trình điều khiển NIC cũ hơn, mất khoảng 2%), nhưng mất mát xảy ra ngay cả ở mức 50Mbit, mặc dù ít nghiêm trọng hơn. Hiệu suất TCP sử dụng các cài đặt tương đương:

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

mang lại tốc độ truyền phía bắc 800Mbit, không có báo cáo truyền lại.

Máy chủ luôn được khởi động bằng các tùy chọn sau:

iperf3 -sB192.168.30.161

Người để đổ lỗi?

  1. Hộp máy khách linux (phần cứng? Trình điều khiển? Cài đặt?)? Chỉnh sửa: Tôi vừa chạy thử nghiệm từ hộp máy chủ Windows này sang hộp máy chủ khác và mức mất gói UDP ở 300Mbit thậm chí còn cao hơn, ở mức 22%
  2. Các hộp máy chủ windows (phần cứng? Trình điều khiển? Cài đặt?)?
  3. Công tắc (đơn) kết nối tất cả các máy kiểm tra?
  4. Cáp?

Biên tập:

Bây giờ tôi đã thử một hướng khác: Windows -> Linux. Kết quả: Mất gói luôn 0 , trong khi thông lượng tối đa ở xung quanh

  • 840Mbit cho -l8192, tức là các gói IP bị phân mảnh
  • 250Mbit cho -l1472, gói IP không phân mảnh

Tôi đoán lưu lượng kiểm soát dòng chảy và ngăn ngừa mất gói. Đặc biệt là phần sau, con số không phân mảnh không ở gần thông lượng TCP (TCP không phân mảnh mang lại số liệu tương tự như TCP bị phân mảnh), nhưng đó là một cải tiến vô cùng lớn so với Linux -> Windows về việc mất gói.

Và làm thế nào để tìm hiểu?

Tôi đã làm theo lời khuyên thông thường cho cài đặt trình điều khiển trên máy chủ để tối đa hóa hiệu suất và cố gắng bật / tắt / tối đa hóa / thu nhỏ / thay đổi

  • Kiểm duyệt ngắt
  • Kiểm soát lưu lượng
  • Nhận được bộ đệm
  • RSS
  • Thức dậy trên mạng LAN

Tất cả các tính năng giảm tải được kích hoạt.

Chỉnh sửa Tôi cũng đã cố gắng bật / tắt

  • Ethernet @ Wirespeed
  • Các tính năng giảm tải khác nhau
  • Ưu tiên & Vlan

Với tỷ lệ tổn thất tương tự.


Đầu ra đầy đủ của một lần chạy 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%)

Chạy 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                  

Câu trả lời:


8

Không có vấn đề gì cả. Đây là hành vi bình thường và dự kiến.

Lý do mất gói là UDP không có bất kỳ kiểm soát tắc nghẽn nào. Trong tcp khi các thuật toán điều khiển tắc nghẽn khởi động, nó sẽ báo cho đầu phát truyền làm chậm việc gửi để tối đa hóa thông lượng và giảm thiểu tổn thất.

Vì vậy, đây là hành vi hoàn toàn bình thường đối với UDP thực sự. UDP không đảm bảo phân phối nếu hàng đợi nhận bị quá tải và sẽ bỏ các gói. Nếu bạn muốn tốc độ truyền cao hơn cho UDP, bạn cần tăng bộ đệm nhận.

Tùy chọn -l hoặc --len iperf sẽ thực hiện thủ thuật. Và có thể cài đặt băng thông đích -b trên máy khách.

-l, --len n [KM] đặt bộ đệm đọc / ghi độ dài thành n (mặc định 8 KB)

8KB ?? đó là một chút về phía nhỏ khi không có kiểm soát tắc nghẽn.

ví dụ về phía máy chủ

~$ iperf -l 1M -U -s

Đây là những gì tôi đưa Linux sang 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

Nhưng đối với UDP sử dụng cài đặt mặc định, tôi chỉ nhận được

~$ 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?

Sau một số thử nghiệm, tôi thấy rằng tôi phải đặt cả chiều dài và mục tiêu băng thông.

~$ 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.

Phía máy chủ:

~$ 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

Để chứng minh mất gói với bộ đệm nhỏ. Thành thật mà nói không phải là cực đoan như tôi mong đợi. Đâu là nguồn đáng tin cậy cho iperf3 mà tôi có thể kiểm tra giữa 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

Phía máy chủ:

~$ 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

Bạn cũng đã xem trang github iperf3 readme chưa?

Các vấn đề đã biết

Hiệu suất UDP: Một số vấn đề đã được chú ý với iperf3 trên ESnet 100G được thử nghiệm ở tốc độ UDP cao (trên 10Gbps). Triệu chứng là trên bất kỳ hoạt động cụ thể nào của iperf3, người nhận báo cáo tỷ lệ mất khoảng 20%, bất kể tùy chọn -b được sử dụng ở phía máy khách. Vấn đề này dường như không phải là đặc thù của iperf3 và có thể là do vị trí của quá trình iperf3 trên CPU và mối quan hệ của nó với NIC gửi đến. Trong một số trường hợp, vấn đề này có thể được giảm thiểu bằng cách sử dụng tùy chọn ái lực CPU (-A) thích hợp. (Vấn đề # 55)

Bạn đang sử dụng một NIC chậm hơn nhưng tôi tự hỏi nếu nó có liên quan.


Vâng và đối với việc mất gói, tôi sẽ chỉ cho bạn cách điều này có thể xảy ra. cập nhật câu trả lời.
Matt

Cảm ơn Matt, chỉ cần xem cập nhật của bạn. Iperf của tôi (trên cả máy chủ Windows và máy khách Linux) là phiên bản 2.0.5. Của bạn là gì
Eugene Beresovsky

Giống nhau. Và trên thực tế khi tôi đặt băng thông mục tiêu thành 1G, tôi nhận được tốc độ băng thông bonkas là 14756449370562973696 Byte / giây và đầu ra bị hỏng như vậy. Vì vậy, tôi nghĩ rằng nó có thể bị hỏng. Tuy nhiên, tôi nghĩ rằng các vấn đề là bộ đệm ... Tôi biết các cửa sổ thực hiện một số điều bất thường với bộ đệm TCP và UDP.
Matt

Lạ thật. Sau ngày hôm nay có lẽ tôi sẽ có quyền truy cập vào môi trường sản xuất 10G tốt và sẽ thả iperf3 trên đó. Chúng ta hãy xem điều đó diễn ra như thế nào.
Eugene Beresovsky

1
Tôi nghĩ rằng bạn hiểu sai những gì công -ltắc làm. Nó không đặt kích thước bộ đệm; Nó đặt kích thước gói. Đây là lượng dữ liệu iperf3 sẽ ghi vào ổ cắm trong một lần và đọc từ ổ cắm trong một lần. Bạn có thể đặt kích thước bộ đệm ổ cắm bằng cách sử dụng -w. Nếu bạn nhìn vào nguồn, bạn sẽ thấy nó gọi setsockopt()để đặt kích thước bộ đệm ổ cắm thành bất cứ thứ gì bạn chỉ định sau -w.
András Korn

0

Bạn hoàn toàn bỏ lỡ thủ phạm rõ ràng nhất - bộ điều hợp và sau đó là trình điều khiển (bạn nói rằng sử dụng trình điều khiển phiên bản khác nhau mang lại kết quả khác nhau).

Hãy thử tắt tất cả các khả năng giảm tải.


Điều đó không giúp được gì - câu hỏi được cập nhật tương ứng.
Eugene Beresovsky
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.