Wifi TCP iperf пропускная способность: 1 поток против нескольких потоков?

В тестировании пропускной способности TCP-протокола WLAN iperf несколько параллельных потоков дадут мне более высокую пропускную способность, чем 1 поток. Я попытался увеличить размер окна TCP, но я все еще не могу достичь максимальной пропускной способности всего за 1 поток. Есть ли что-то еще в слое TCP, препятствующее использованию полной пропускной способности?

12 голосов | спросил elin05 16 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowMon, 16 Sep 2013 23:11:32 +0400 2013, 23:11:32

3 ответа


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% -ную потерю, покинув клиентскую сетевую карту. 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

EDIT для комментариев :

  

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

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

  

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

Да

  

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

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

  

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

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

Однопоточная пропускная способность Wi-Fi TCP


Данные тестирования

Я также включаю необработанные тестовые данные, если вы хотите увидеть, как я измерил эти вещи ...

802.11g, 1 TCP-поток

[email protected]:~$ 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
[email protected]:~$

[[email protected]]$ iperf -s -p 9000 -B 172.16.1.5

[email protected]:~$ 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
[email protected]:~$

802.11g, 5 потоков TCP

[[email protected]]$ iperf -s -p 9001 -B 172.16.1.5

[email protected]:~$ 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
[email protected]:~$

1000BaseT, 1 поток, потеря 0.0%

[email protected]:~$ 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
[email protected]:~$

[[email protected]]$ iperf -s -p 9002 -B 172.16.1.5

[email protected]:~$ 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
[email protected]:~$

1000BaseT, 5 потоков, потеря 0.0%

[[email protected]]$ iperf -s -p 9003 -B 172.16.1.5

[email protected]:~$ 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
[email protected]:~$

1000BaseT, 1 поток, потеря 2.0%

[email protected]:~$ sudo tc qdisc add dev eth0 root netem corrupt 2.0%

[email protected]:~$ 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
[email protected]:~$

[[email protected]]$ iperf -s -p 9004 -B 172.16.1.5

[email protected]:~$ 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
[email protected]:~$

1000BaseT, 5 потоков, потеря 2.0%

[[email protected]]$ iperf -s -p 9005 -B 172.16.1.5

[email protected]:~$ 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
[email protected]:~$

Удаление моделирования потери пакетов

[email protected]:~$ sudo tc qdisc del dev eth0 root
ответил Mike Pennington 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 17 Sep 2013 14:59:06 +0400 2013, 14:59:06
2

Вот расчет максимальной пропускной способности одного потока tcp.

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

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

ответил James.Birmingham 17 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowTue, 17 Sep 2013 03:04:41 +0400 2013, 03:04:41
0

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

ответил rjmcmahon 15 J000000Friday16 2016, 21:24:39

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132