Wifi TCP iperf thông lượng: 1 luồng so với nhiều luồng?


12

Trong thử nghiệm thông lượng TCP iperf TCP, nhiều luồng song song sẽ cho tôi thông lượng cao hơn 1 luồng. Tôi đã thử tăng kích thước cửa sổ TCP, nhưng tôi vẫn không thể đạt được thông lượng tối đa chỉ với 1 luồng. Có cái gì khác trong lớp TCP đang ngăn chặn khả năng liên kết đầy đủ được sử dụng không?


Bạn quan sát được bao nhiêu sự khác biệt? Lý tưởng nhất, nếu một luồng TCP cung cấp thông lượng T, thì hai luồng sẽ cung cấp thông lượng T / 2 riêng lẻ.
Manoj Pandey

Lưu ý rằng dung lượng liên kết đầy đủ bất kể số lượng luồng sẽ không bao giờ đạt được. IPv4 với các tiêu đề [IP + TCP] tối thiểu sẽ mang lại hiệu suất kênh ~ 95%. Xem bài viết Giao thức tuyệt vời trên sd.wareonearth.com/~phil/net/overhead .
generalnetworkerror

@ManojPandey, tôi không chắc anh ấy đang nhìn thấy một trường hợp lý tưởng ... đặc biệt là khi anh ấy sử dụng wifi ... Tôi nghi ngờ anh ấy bị mất gói ...
Mike Pennington

TCP hút qua Wi-Fi, đối phó với nó. Nếu bạn phải sử dụng nó và bạn đang thấy mất gói tin lớp 3, tôi khuyên bạn nên tăng số lần thử lại tối đa của lớp 2, vì TCP không được thiết kế để xử lý các liên kết bị mất mà không phá hủy hiệu suất.
BatchyX

Câu trả lời:


14

Trong thử nghiệm thông lượng TCP iperf TCP, nhiều luồng song song sẽ cho tôi thông lượng cao hơn 1 luồng. Tôi đã thử tăng kích thước cửa sổ TCP, nhưng tôi vẫn không thể đạt được thông lượng tối đa chỉ với 1 luồng. Có cái gì khác trong lớp TCP đang ngăn chặn khả năng liên kết đầy đủ được sử dụng không?

Theo kinh nghiệm của tôi, nếu bạn thấy kết quả khác nhau đáng kể giữa 1 luồng TCP và nhiều luồng TCP thì vấn đề thường là mất gói; vì vậy "cái gì khác" trong lớp TCP là truyền lại (do mất gói lớp thấp hơn).

Một ví dụ tôi đã nấu để minh họa mức độ mất gói ảnh hưởng đến thông lượng một luồng ...

                   [Wifi||LAN-0.0%-Loss||LAN-2.0%-Loss]
+--------------+                                        +--------------+
|              |                                        |              |
| Thinkpad-T61 |----------------------------------------| Linux Server |
|              |                                        | Tsunami      |
+--------------+                                        +--------------+
iperf client             ------------------>            iperf server
                             Pushes data

Đây là bảng tóm tắt kết quả kiểm tra của thử nghiệm 60 giây iperfgiữa máy khách và máy chủ ... bạn có thể thấy một chút thay đổi trong kết quả iperf từ jitter RTT (nghĩa là độ lệch chuẩn RTT cao hơn); tuy nhiên, sự khác biệt đáng kể nhất xảy ra khi tôi mô phỏng mất 2% khi rời máy khách có dây. 172.16.1.56 và 172.16.1.80 là cùng một máy tính xách tay (chạy Ubuntu). Máy chủ là 172.16.1.5, chạy Debian. Tôi đã sử dụng netem trên máy khách có dây NIC để mô phỏng việc mất gói ...

Client IP       Transport    Loss     avg RTT    RTT StdDev    TCP Streams   Tput
-----------     ----------   ----     -------    ----------    -----------   ----------
172.16.1.56     802.11g      0.0%      0.016s          42.0              1     19.5Mbps
172.16.1.56     802.11g      0.0%      0.016s          42.0              5     20.5Mbps
172.16.1.80     1000BaseT    0.0%     0.0002s           0.0              1    937  Mbps
172.16.1.80     1000BaseT    0.0%     0.0002s           0.0              5    937  Mbps
172.16.1.80     1000BaseT    2.0%     0.0002s           0.0              1    730  Mbps <---
172.16.1.80     1000BaseT    2.0%     0.0002s           0.0              5    937  Mbps

EDIT cho phản hồi bình luận :

Bạn có thể giải thích những gì đang xảy ra trong kịch bản cuối cùng (1000BaseT, 5 luồng, mất 2,0%) không? Mặc dù có mất gói, tổng thông lượng vẫn bão hòa ở mức 937 Mbits / giây.

Hầu hết các cài đặt TCP giảm cửa sổ tắc nghẽn của chúng khi phát hiện mất gói. Vì chúng tôi đang sử dụng netem để buộc mất 2% gói từ máy khách đến máy chủ, một số dữ liệu của máy khách sẽ bị hủy. Hiệu ứng ròng của netem trong ví dụ này là tốc độ truyền trung bình một luồng là 730Mbps. Thêm nhiều luồng có nghĩa là các luồng TCP riêng lẻ có thể hoạt động cùng nhau để bão hòa liên kết.

Mục tiêu của tôi là đạt được thông lượng TCP cao nhất có thể qua WiFi. Theo tôi hiểu, tôi nên tăng số lượng luồng để chống lại sự giảm thông lượng gây ra do mất gói. Điều này có đúng không?

Đúng

Ngoài ra, tại thời điểm nào sẽ có quá nhiều luồng bắt đầu tác động tiêu cực đến thông lượng? Điều này sẽ được gây ra bởi bộ nhớ hạn chế và / hoặc sức mạnh xử lý?

Tôi thực sự không thể trả lời rằng nếu không có nhiều thử nghiệm hơn, nhưng đối với các liên kết 1GE, tôi chưa bao giờ gặp sự cố khi bão hòa một liên kết với 5 luồng song song. Để cung cấp cho bạn ý tưởng về khả năng mở rộng của TCP, các máy chủ linux có thể xử lý hơn 1500 ổ cắm TCP đồng thời trong các trường hợp phù hợp. Đây là một cuộc thảo luận SO khác có liên quan đến việc mở rộng các socket TCP đồng thời, nhưng theo tôi, bất cứ điều gì trên 20 socket song song sẽ là quá mức nếu bạn chỉ cố gắng bão hòa một liên kết.

Tôi phải có một sự hiểu lầm rằng iperf sử dụng kích thước cửa sổ -w là tối đa vì có vẻ như bạn đang nói rằng nó đã vượt quá giá trị ban đầu 21K đó

Tôi đã không sử dụng iperf -w, vì vậy tôi nghĩ rằng có một sự hiểu lầm. Vì bạn có quá nhiều câu hỏi về trường hợp wifi, tôi bao gồm một biểu đồ thông lượng về thông lượng TCP cho trường hợp phát sóng TCP đơn.

Thông lượng truyền phát một chiều TCP TCP


Kiểm tra dữ liệu

Tôi cũng bao gồm dữ liệu thử nghiệm thô trong trường hợp bạn muốn xem cách tôi đo những thứ này ...

802.11g, 1 luồng TCP

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report \
  --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 0.0%    60    0.8  16.0   0.7 189.4  42.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9000 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9000 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9000
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.56 port 40376 connected with 172.16.1.5 port 9000
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.1 sec   139 MBytes  19.5 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

802.11g, 5 luồng TCP

[mpenning@tsunami]$ iperf -s -p 9001 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9001 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9001
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.56 port 37162 connected with 172.16.1.5 port 9001
[  5] local 172.16.1.56 port 37165 connected with 172.16.1.5 port 9001
[  7] local 172.16.1.56 port 37167 connected with 172.16.1.5 port 9001
[  4] local 172.16.1.56 port 37163 connected with 172.16.1.5 port 9001
[  6] local 172.16.1.56 port 37166 connected with 172.16.1.5 port 9001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  28.0 MBytes  3.91 Mbits/sec
[  5]  0.0-60.1 sec  28.8 MBytes  4.01 Mbits/sec
[  4]  0.0-60.3 sec  28.1 MBytes  3.91 Mbits/sec
[  6]  0.0-60.4 sec  34.0 MBytes  4.72 Mbits/sec
[  7]  0.0-61.0 sec  30.5 MBytes  4.20 Mbits/sec
[SUM]  0.0-61.0 sec   149 MBytes  20.5 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 1 luồng, mất 0,0%

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report \
>   --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 0.0%    60    0.2   0.2   0.2   0.2   0.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9002 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9002 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9002
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.80 port 49878 connected with 172.16.1.5 port 9002
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  6.54 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 5 luồng, mất 0,0%

[mpenning@tsunami]$ iperf -s -p 9003 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9003 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9003
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  7] local 172.16.1.80 port 47047 connected with 172.16.1.5 port 9003
[  3] local 172.16.1.80 port 47043 connected with 172.16.1.5 port 9003
[  4] local 172.16.1.80 port 47044 connected with 172.16.1.5 port 9003
[  5] local 172.16.1.80 port 47045 connected with 172.16.1.5 port 9003
[  6] local 172.16.1.80 port 47046 connected with 172.16.1.5 port 9003
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-60.0 sec  1.28 GBytes   184 Mbits/sec
[  5]  0.0-60.0 sec  1.28 GBytes   184 Mbits/sec
[  3]  0.0-60.0 sec  1.28 GBytes   183 Mbits/sec
[  6]  0.0-60.0 sec  1.35 GBytes   193 Mbits/sec
[  7]  0.0-60.0 sec  1.35 GBytes   193 Mbits/sec
[SUM]  0.0-60.0 sec  6.55 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 1 luồng, mất 2,0%

mpenning@mpenning-ThinkPad-T61:~$ sudo tc qdisc add dev eth0 root netem corrupt 2.0%

mpenning@mpenning-ThinkPad-T61:~$ mtr --no-dns --report   --report-cycles 60 172.16.1.5
HOST: mpenning-ThinkPad-T61       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 172.16.1.5                 1.7%    60    0.2   0.2   0.2   0.2   0.0
mpenning@mpenning-ThinkPad-T61:~$

[mpenning@tsunami]$ iperf -s -p 9004 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9004 -t 60 -P 1
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9004
TCP window size: 42.0 KByte (default)
------------------------------------------------------------
[  3] local 172.16.1.80 port 48910 connected with 172.16.1.5 port 9004
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-64.1 sec  5.45 GBytes   730 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

1000BaseT, 5 luồng, mất 2,0%

[mpenning@tsunami]$ iperf -s -p 9005 -B 172.16.1.5

mpenning@mpenning-ThinkPad-T61:~$ iperf -c 172.16.1.5 -p 9005 -t 60 -P 5
------------------------------------------------------------
Client connecting to 172.16.1.5, TCP port 9005
TCP window size: 21.0 KByte (default)
------------------------------------------------------------
[  7] local 172.16.1.80 port 50616 connected with 172.16.1.5 port 9005
[  3] local 172.16.1.80 port 50613 connected with 172.16.1.5 port 9005
[  5] local 172.16.1.80 port 50614 connected with 172.16.1.5 port 9005
[  4] local 172.16.1.80 port 50612 connected with 172.16.1.5 port 9005
[  6] local 172.16.1.80 port 50615 connected with 172.16.1.5 port 9005
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  1.74 GBytes   250 Mbits/sec
[  7]  0.0-60.0 sec   711 MBytes  99.3 Mbits/sec
[  4]  0.0-60.0 sec  1.28 GBytes   183 Mbits/sec
[  6]  0.0-60.0 sec  1.59 GBytes   228 Mbits/sec
[  5]  0.0-60.0 sec  1.24 GBytes   177 Mbits/sec
[SUM]  0.0-60.0 sec  6.55 GBytes   937 Mbits/sec
mpenning@mpenning-ThinkPad-T61:~$

Xóa mô phỏng mất gói

mpenning@mpenning-ThinkPad-T61:~$ sudo tc qdisc del dev eth0 root

Bạn có thể giải thích những gì đang xảy ra trong kịch bản cuối cùng (1000BaseT, 5 luồng, mất 2,0%) không? Mặc dù có mất gói, tổng thông lượng vẫn bão hòa ở mức 937 Mbits / giây. Mục tiêu của tôi là đạt được thông lượng TCP cao nhất có thể qua WiFi. Theo tôi hiểu, tôi nên tăng số lượng luồng để chống lại sự giảm thông lượng gây ra do mất gói. Điều này có đúng không? Ngoài ra, tại thời điểm nào sẽ có quá nhiều luồng bắt đầu tác động tiêu cực đến thông lượng? Điều này sẽ được gây ra bởi bộ nhớ hạn chế và / hoặc sức mạnh xử lý?
elin05

@ elin05: Sử dụng nhiều luồng sẽ làm mất gói tin trên một số luồng, vì vậy khi xảy ra mất gói, chỉ một luồng sẽ giảm kích thước cửa sổ TCP của nó, khiến các luồng khác không bị ảnh hưởng.
BatchyX

Không phải cuộc gọi BDP 802.11g (54Mbps) cho kích thước cửa sổ 54KB với độ trễ 8ms (16ms RTT / 2) để giữ cho đường ống đầy với các gói trong chuyến bay? Kích thước cửa sổ ở phía máy chủ là bao nhiêu?
generalnetworkerror

@generalnetworkerror, các cửa sổ TCP không tĩnh ... chúng thay đổi dựa trên nhu cầu của TCP ... trong quá trình chụp đó, kích thước cửa sổ tối đa mà Tsunami quảng cáo là 1177600 byte; Cửa sổ trung bình của sóng thần là 1045083 byte và RTT trung bình trong thử nghiệm 60 giây đó là 32,2ms.
Mike Pennington

@MikePennington: Tôi phải hiểu nhầm rằng iperf sử dụng kích thước cửa sổ -w ở mức tối đa vì có vẻ như bạn đang nói rằng nó đã vượt quá giá trị ban đầu 21K đó.
generalnetworkerror

2

Đây là phép tính cho thông lượng tối đa của một luồng tcp.

(TCP Window [bytes]/RTT[seconds]) * 8 [bits/byte] = Max single tcp throughput in (bps)

Vì vậy, bạn có một nút cổ chai và độ trễ đóng một vai trò lớn.


0

Có lẽ là do nhiều quá trình so với một quá trình. với iperf 2.0.9, người ta có thể kiểm tra điều này thông qua -P 2 trên máy khách. Điều này sẽ rẽ nhánh hai chủ đề thay vì một. Hầu hết các CPU hiện đại đều có nhiều lõi nên sử dụng nhiều luồng sẽ có thể tận dụng chúng.

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.