Пропускная способность Wi-Fi 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, я не уверен, что он видит идеальный случай ... тем более, что он использует Wi-Fi ... Я подозреваю, что у него потеря пакетов ...

— Майк Пеннингтон

TCP отстой по Wi-Fi, разберись с этим. Если вам нужно его использовать, и вы видите потери пакетов уровня 3, я бы предложил увеличить максимальное количество повторных попыток уровня 2, поскольку 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% потерь, оставив клиентский сетевой адаптер. 172.16.1.56 и 172.16.1.80 - это один и тот же ноутбук (работает под управлением Ubuntu). Сервер 172.16.1.5, на котором запущен Debian. Я использовал netem на проводной сетевой плате клиента для симуляции потери пакетов ...

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

РЕДАКТИРОВАТЬ для комментариев комментариев :

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

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

Моя цель - добиться максимальной пропускной способности TCP через WiFi. Насколько я понимаю, я должен увеличить количество потоков, чтобы противостоять снижению пропускной способности, вызванному потерей пакетов. Это верно?

да

Кроме того, в какой момент слишком много потоков начнет негативно влиять на пропускную способность? Будет ли это вызвано ограниченной памятью и / или вычислительной мощностью?

Я не могу ответить на этот вопрос без дополнительных экспериментов, но для ссылок 1GE у меня никогда не возникало проблем с насыщением ссылки 5 параллельными потоками. Чтобы дать вам представление о масштабируемости TCP, серверы linux могут обрабатывать более 1500 одновременных сокетов TCP при правильных обстоятельствах. Это еще одно SO-обсуждение, которое имеет отношение к масштабированию параллельных сокетов TCP, но, на мой взгляд, все, что выше 20 параллельных сокетов, будет излишним, если вы просто пытаетесь насытить ссылку.

У меня должно быть неправильное представление о том, что iperf использует максимальный размер окна -w, как будто вы говорите, что он превысил первоначальное значение 21K

Я не использовал iperf -w, поэтому я думаю, что есть недоразумение. Поскольку у вас так много вопросов по поводу случая Wi-Fi, я включил график Wireshark для пропускной способности TCP для случая Wi-Fi с одним TCP.

Wi-Fi 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 Streams, потеря 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

Разве 802.11g (54 Мбит / с) BDP не требует размера окна 54 КБ с задержкой 8 мс (16 мс RTT / 2), чтобы сохранить канал заполненным пакетами в полете? Какой размер окна на стороне сервера?

— generalnetworkerror

@generalnetworkerror, окна TCP не являются статичными ... они изменяются в зависимости от потребностей TCP ... во время этого захвата максимальный размер окна, объявленный Tsunami, составлял 1177600 байт; Среднее окно Tsunami составляло 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)

Таким образом, у вас есть узкое место, и латентность играет большую роль.

— James.Birmingham
источник

Вероятно, это связано с несколькими процессами против одного процесса. с iperf 2.0.9 это можно проверить через -P 2 на клиенте. Это разветвляет два потока вместо одного. Большинство современных процессоров имеют несколько ядер, поэтому использование нескольких потоков позволит использовать их.

— rjmcmahon
источник