Пропускна здатність Wifi TCP iperf: 1 потік проти кількох потоків?


12

У тесті на пропускну здатність TCP для WLAN iperf кілька паралельних потоків дають мені більшу пропускну здатність, ніж 1 потік. Я спробував збільшити розмір вікна TCP, але все ще не можу досягти максимальної пропускної здатності лише з 1 потоку. Чи є ще щось у шарі TCP, що перешкоджає використанню повної ємності посилання?


Скільки різниці ви спостерігаєте? В ідеалі, якщо один потік TCP забезпечує пропускну здатність T, два повинні індивідуально забезпечувати пропускну здатність T / 2 кожен.
Маной Пандей

Зауважте, що повна потужність зв'язку незалежно від кількості потоків ніколи не буде досягнута. IPv4 з мінімальними заголовками [IP + TCP] дасть ~ 95% ефективність каналу. Дивіться чудову публікацію протокольних накладних на веб- сайті sd.wareonearth.com/~phil/net/overhead .
generalnetworkerror

@ManojPandey, я не впевнений, що він бачить ідеальний випадок ... тим більше, що він використовує wifi ... Я підозрюю, що у нього є деякі втрати пакету ...
Майк Пеннінгтон,

TCP смокче через Wi-Fi, займайтеся цим. Якщо вам доведеться його використовувати, і ви бачите втрати пакетів 3 рівня, я б запропонував збільшити максимальну кількість повторних спроб, оскільки TCP не призначений для обробки втрат посилань, не руйнуючи продуктивність.
BatchyX

Відповіді:


14

У тесті на пропускну здатність TCP для WLAN iperf кілька паралельних потоків дають мені більшу пропускну здатність, ніж 1 потік. Я спробував збільшити розмір вікна TCP, але все ще не можу досягти максимальної пропускної здатності лише з 1 потоку. Чи є ще щось у шарі TCP, що перешкоджає використанню повної ємності посилання?

На мій досвід, якщо ви бачите суттєво різні результати між 1 потоком TCP та кількома потоками TCP, проблема, як правило, втрата пакету; тому "щось інше" у шарі TCP - це повторна передача (через втрати пакету нижнього рівня).

Приклад, який я підготував, щоб проілюструвати, як втрата пакету впливає на пропускну спроможність одного потоку ...

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

Це таблиця, яка підсумовує результати тесту 60-секундного iperfтесту між клієнтом і сервером ... ви можете побачити невеликі зміни в результатах iperf від тремтіння RTT (тобто більш високе стандартне відхилення RTT); однак найзначніша різниця виявилася, коли я імітував втрати на 2%, залишаючи клієнтський провідний NIC. 172.16.1.56 та 172.16.1.80 - той самий ноутбук (під керуванням Ubuntu). Сервер 172.16.1.5, працює Debian. Я використовував Netem на клієнтському проводному NIC для імітації втрат пакету ...

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 для коментарів :

Чи можете ви пояснити, що відбувається за останнім сценарієм (1000BaseT, 5 потоків, 2,0% втрати)? Незважаючи на втрати пакетів, загальна пропускна здатність все ще насичена 937 Мбіт / с.

Більшість реалізацій TCP зменшують вікно перевантаженості, коли виявляються втрати пакету. Оскільки ми використовуємо netem, щоб примусити 2% втрати пакету від клієнта до сервера, частина клієнтських даних втрачається. Чистий ефект нетема в цьому прикладі - це однопотокова середня швидкість передачі 730 Мбіт / с. Додавання декількох потоків означає, що окремі потоки TCP можуть працювати разом для насичення зв'язку.

Моя мета - досягти максимальної пропускної здатності TCP через WiFi. Як я це розумію, я повинен збільшити кількість потоків, щоб протиставити зменшенню пропускної здатності, викликаної втратою пакету. Це правильно?

Так

Крім того, в який момент занадто багато потоків почне негативно впливати на пропускну здатність? Це буде викликано обмеженою пам'яттю та / або потужністю обробки?

Я справді не можу відповісти на це без додаткових експериментів, але для посилань 1GE у мене ніколи не було проблеми з насиченням зв'язку з 5 паралельними потоками. Щоб дати вам уявлення про те, наскільки масштабований TCP, Linux-сервери можуть обробляти понад 1500 одночасних TCP-сокетів за правильних обставин. Це ще одне обговорення SO, яке стосується масштабування паралельних сокетів TCP, але, на мою думку, все, що перевищує 20 паралельних розеток, було б надмірним, якщо ви просто намагаєтесь наситити посилання.

Я повинен мати непорозуміння, що iperf використовує -w розмір вікна як максимум, оскільки це звучить так, як ви говорите, що він перевищив початкове значення 21K

Я не користувався iperf -w, тому думаю, що є непорозуміння. Оскільки у вас є стільки запитань щодо випадку Wi-Fi, я включаю графік проводів пропускної здатності TCP для єдиного випадку потоку протоколу TCP Wi-Fi.

Однопотокова пропускна здатність Wifi TCP


Дані тесту

Я також включаю необроблені дані тесту на випадок, якщо ви хочете подивитися, як я вимірював ці речі ...

802.11g, 1 потік 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 потоків 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 потік, втрата 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 потоків, втрата 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 потік, 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 потоків, втрата на 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:~$

Видаліть моделювання втрат пакетів

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

Чи можете ви пояснити, що відбувається за останнім сценарієм (1000BaseT, 5 потоків, 2,0% втрати)? Незважаючи на втрати пакетів, загальна пропускна здатність все ще насичена 937 Мбіт / с. Моя мета - досягти максимальної пропускної здатності TCP через WiFi. Як я це розумію, я повинен збільшити кількість потоків, щоб протиставити зменшенню пропускної здатності, викликаної втратою пакету. Це правильно? Крім того, в який момент занадто багато потоків почне негативно впливати на пропускну здатність? Це буде викликано обмеженою пам'яттю та / або потужністю обробки?
elin05

@ elin05: Використання декількох потоків поширює втрати пакету на декілька потоків, тому при втраті пакету лише один потік зменшить розмір його вікна TCP, залишивши інші потоки не зачепленими.
BatchyX

Чи не BDP 802.11g (54Mbps) BDP вимагає розміру вікна 54KB із затримкою 8 мс (16 мс RTT / 2), щоб труба була заповнена пакетами під час польоту? Який розмір вікна на стороні сервера?
generalnetworkerror

@generalnetworkerror, вікна TCP не є статичними ... вони змінюються, виходячи з потреб TCP ... під час цього захоплення максимальний розмір вікна, який рекламується Цунамі, становив 1177600 байт; Середнє вікно цунамі становило 1045083 байт, а середня RTT за 60 секунд тест - 32,2 мс.
Майк Пеннінгтон

@MikePennington: Я повинен мати непорозуміння, що iperf використовує -w розмір вікна як максимум, оскільки це звучить так, як ви говорите, що він перевищив початкове значення 21K.
generalnetworkerror

2

Ось розрахунок максимальної пропускної здатності одного потоку tcp.

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

Тож у вас вузьке місце і затримка відіграє велику роль.


0

Ймовірно, це пов'язано з декількома процесами проти одного процесу. з iperf 2.0.9 можна перевірити це через -P 2 на клієнті. Це роздвоює дві нитки замість однієї. Більшість сучасних процесорів мають декілька ядер, тому використання декількох потоків зможе використовувати їх.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.