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

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

— elin05
джерело

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

— Маной Пандей

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

— generalnetworkerror

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

— Майк Пеннінгтон,

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

— BatchyX

У тесті на пропускну здатність 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

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

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

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

— Джеймс Бірмінгем
джерело

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

— rjmcmahon
джерело