Экстремальные потери пакетов UDP при 300 Мбит (14%), но TCP> 800 Мбит без повторной передачи

11

У меня есть linux box, который я использую в качестве iperf3клиента, тестирую 2 одинаково оборудованных серверных блока Windows 2012 R2 с адаптерами Broadcom BCM5721, 1 Гб (2 порта, но для тестирования использовался только 1). Все машины подключены через один 1Gb коммутатор.

Тестирование UDP, например, на 300 Мбит

iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192

приводит к потере 14% всех отправленных пакетов (для другой серверной коробки с точно таким же оборудованием, но с более старыми драйверами NIC потеря составляет около 2%), но потеря происходит даже на 50 Мбит, хотя и менее серьезно. Производительность TCP с использованием эквивалентных настроек:

iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192

дает скорость передачи к северу от 800 Мбит без повторных передач.

Сервер всегда запускается с использованием следующих параметров:

iperf3 -sB192.168.30.161

Кто виноват?

  1. Клиентский ящик linux (аппаратные «драйвера», «настройки») Изменить: Я только что провел тест с одного сервера Windows на другой, и потеря пакетов UDP на 300 Мбит был еще выше, на 22%
  2. Windows Server Box (аппаратные «драйвер» настройки »)?
  3. (Единственный) переключатель, который соединяет все тестовые машины?
  4. Кабели?

Редактировать:

Сейчас я попробовал другое направление: Windows -> Linux. Результат: потеря пакетов всегда равна 0 , а пропускная способность максимально

  • 840Мбит для -l8192, т.е. фрагментированных IP-пакетов
  • 250 Мбит для -l1472нефрагментированных IP-пакетов

Я предполагаю, что контроль потока ограничивает пропускную способность и предотвращает потерю пакетов. Особенно последняя, ​​нефрагментированная цифра далеко не соответствует пропускной способности TCP (нефрагментированная TCP дает аналогичные показатели для фрагментированной TCP), но это бесконечно огромное улучшение по сравнению с Linux -> Windows с точки зрения потери пакетов.

А как узнать?

Я следовал обычному совету по настройке драйверов на сервере, чтобы максимизировать производительность, и попытался включить / отключить / развернуть / свернуть / изменить

  • Модерация прерываний
  • Управление потоком
  • Получите буферы
  • RSS
  • Wake On LAN

Все функции разгрузки включены.

Редактировать Я также пытался включить / отключить

  • Ethernet @ Wirespeed
  • Различные функции разгрузки
  • Приоритет & VLAN

С аналогичными показателями потерь.


Полный вывод запуска UDP:

$ iperf3 -uZVc 192.168.30.161 -b300m -t5 --get-server-output -l8192
iperf 3.0.7
Linux mybox 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux
Time: Wed, 13 May 2015 13:10:39 GMT
Connecting to host 192.168.30.161, port 5201   
      Cookie: mybox.1431522639.098587.3451f174
[  4] local 192.168.30.202 port 50851 connected to 192.168.30.161 port 5201
Starting Test: protocol: UDP, 1 streams, 8192 byte blocks, omitting 0 seconds, 5 second test
[ ID] Interval           Transfer     Bandwidth       Total Datagrams
[  4]   0.00-1.00   sec  33.3 MBytes   279 Mbits/sec  4262
[  4]   1.00-2.00   sec  35.8 MBytes   300 Mbits/sec  4577
[  4]   2.00-3.00   sec  35.8 MBytes   300 Mbits/sec  4578
[  4]   3.00-4.00   sec  35.8 MBytes   300 Mbits/sec  4578
[  4]   4.00-5.00   sec  35.8 MBytes   300 Mbits/sec  4577
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-5.00   sec   176 MBytes   296 Mbits/sec  0.053 ms  3216/22571 (14%)
[  4] Sent 22571 datagrams
CPU Utilization: local/sender 4.7% (0.4%u/4.3%s), remote/receiver 1.7% (0.8%u/0.9%s)

Server output:
-----------------------------------------------------------
Accepted connection from 192.168.30.202, port 44770
[  5] local 192.168.30.161 port 5201 connected to 192.168.30.202 port 50851
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  5]   0.00-1.01   sec  27.2 MBytes   226 Mbits/sec  0.043 ms  781/4261 (18%)
[  5]   1.01-2.01   sec  30.0 MBytes   252 Mbits/sec  0.058 ms  734/4577 (16%)
[  5]   2.01-3.01   sec  29.0 MBytes   243 Mbits/sec  0.045 ms  870/4578 (19%)
[  5]   3.01-4.01   sec  32.1 MBytes   269 Mbits/sec  0.037 ms  469/4579 (10%)
[  5]   4.01-5.01   sec  32.9 MBytes   276 Mbits/sec  0.053 ms  362/4576 (7.9%)

TCP работает:

$ iperf3 -ZVc 192.168.30.161 -t5 --get-server-output -l8192
iperf 3.0.7
Linux mybox 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux
Time: Wed, 13 May 2015 13:13:53 GMT
Connecting to host 192.168.30.161, port 5201   
      Cookie: mybox.1431522833.505583.4078fcc1
      TCP MSS: 1448 (default)
[  4] local 192.168.30.202 port 44782 connected to 192.168.30.161 port 5201
Starting Test: protocol: TCP, 1 streams, 8192 byte blocks, omitting 0 seconds, 5 second test
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec   109 MBytes   910 Mbits/sec    0   91.9 KBytes       
[  4]   1.00-2.00   sec  97.3 MBytes   816 Mbits/sec    0   91.9 KBytes       
[  4]   2.00-3.00   sec  97.5 MBytes   818 Mbits/sec    0   91.9 KBytes       
[  4]   3.00-4.00   sec  98.0 MBytes   822 Mbits/sec    0   91.9 KBytes       
[  4]   4.00-5.00   sec  97.6 MBytes   819 Mbits/sec    0   91.9 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-5.00   sec   499 MBytes   837 Mbits/sec    0             sender
[  4]   0.00-5.00   sec   498 MBytes   836 Mbits/sec                  receiver
CPU Utilization: local/sender 3.5% (0.5%u/3.0%s), remote/receiver 4.5% (2.0%u/2.5%s)

Server output:
-----------------------------------------------------------
Accepted connection from 192.168.30.202, port 44781
[  5] local 192.168.30.161 port 5201 connected to 192.168.30.202 port 44782
[ ID] Interval           Transfer     Bandwidth
[  5]   0.00-1.00   sec   105 MBytes   878 Mbits/sec                  
[  5]   1.00-2.00   sec  97.5 MBytes   818 Mbits/sec                  
[  5]   2.00-3.00   sec  97.6 MBytes   819 Mbits/sec                  
[  5]   3.00-4.00   sec  97.8 MBytes   820 Mbits/sec                  
[  5]   4.00-5.00   sec  97.7 MBytes   820 Mbits/sec                  
Евгений Бересовский
источник

Ответы:

8

Нет проблем. Это нормальное и ожидаемое поведение.

Причиной потери пакета является то, что UDP не контролирует перегрузку. В tcp, когда включаются алгоритмы управления перегрузкой, передающая сторона сообщает, чтобы замедлить передачу, чтобы максимизировать пропускную способность и минимизировать потери.

Так что на самом деле это абсолютно нормальное поведение для UDP. UDP не гарантирует доставку, если очередь приема перегружена и отбрасывает пакеты. Если вы хотите более высокие скорости передачи для UDP, вам нужно увеличить приемный буфер.

Опция -l или --len iperf должна помочь. И, возможно, целевой целевой пропускной способности -b на клиенте.

-l, --len n [KM] установить буфер чтения / записи длины в n (по умолчанию 8 КБ)

8KB ?? это немного на маленькой стороне, когда нет контроля заторов.

например, на стороне сервера.

~$ iperf -l 1M -U -s

Это то, что я получаю Linux в Linux

Client connecting to ostore, TCP port 5001
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 35399 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.10 GBytes   943 Mbits/sec

Но для UDP используя настройки по умолчанию я получаю только

~$ iperf -u -c ostore 
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 1470 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 52898 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec
[  3] Sent 893 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec  1.25 MBytes  1.05 Mbits/sec   0.027 ms    0/  893 (0%)

WT?

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

~$ iperf -u -c ostore -l 8192 -b 1G
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 8192 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 60237 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.12 GBytes   958 Mbits/sec
[  3] Sent 146243 datagrams
[  3] WARNING: did not receive ack of last datagram after 10 tries.

Сторона сервера:

~$ iperf -s -u -l 5M 
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 5242880 byte datagrams
UDP buffer size:  224 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 36448
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.1 sec  1008 KBytes   819 Kbits/sec   0.018 ms    0/  126 (0%)
[  4] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 60237
[  4]  0.0-10.0 sec  1.12 GBytes   958 Mbits/sec   0.078 ms    0/146242 (0%)
[  4]  0.0-10.0 sec  1 datagrams received out-of-order

Для демонстрации потери пакетов с небольшими буферами. Что, честно говоря, не так экстремально, как я ожидал. Где надежный источник для iperf3, который я могу проверить между Linux / Windows?

~$ iperf -u -c ostore -l 1K -b 1G
------------------------------------------------------------
Client connecting to ostore, UDP port 5001
Sending 1024 byte datagrams
UDP buffer size:  208 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.107 port 45061 connected with 192.168.0.10 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec   674 MBytes   565 Mbits/sec
[  3] Sent 689777 datagrams
[  3] Server Report:
[  3]  0.0-10.0 sec   670 MBytes   562 Mbits/sec   0.013 ms 3936/689776 (0.57%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

Сторона сервера:

~$ iperf -s -u -l 1K 
------------------------------------------------------------
Server listening on UDP port 5001
Receiving 1024 byte datagrams
UDP buffer size:  224 KByte (default)
------------------------------------------------------------
[  3] local 192.168.0.10 port 5001 connected with 192.168.0.107 port 45061
[ ID] Interval       Transfer     Bandwidth        Jitter   Lost/Total Datagrams
[  3]  0.0-10.0 sec   670 MBytes   562 Mbits/sec   0.013 ms 3936/689776 (0.57%)
[  3]  0.0-10.0 sec  1 datagrams received out-of-order

Вы также просматривали страницу чтения iperf3 github ?

Известные вопросы

Производительность UDP: Некоторые проблемы были замечены с iperf3 на стенде ESnet 100G при высоких скоростях UDP (выше 10 Гбит / с). Признак состоит в том, что при любом конкретном запуске iperf3 получатель сообщает о потере около 20%, независимо от опции -b, используемой на стороне клиента. Эта проблема, по-видимому, не связана с iperf3 и может быть связана с размещением процесса iperf3 на ЦП и его отношением к входящему NIC. В некоторых случаях эта проблема может быть смягчена путем соответствующего использования опции привязки к процессору (-A). (Выпуск № 55)

Вы используете более медленный NIC, но мне интересно, связано ли это.

Matt
источник
Да, а что касается потери пакетов, я покажу вам, как это может произойти. Обновление ответа.
Мэтт
Спасибо Мэтт, только что увидел ваше обновление. Мой iperf (как на сервере Windows, так и на клиенте Linux) - версия 2.0.5. Что твое?
Евгений Бересовский
Такой же. И на самом деле, когда я устанавливаю целевую полосу пропускания в 1G, я получаю пропускную способность bonkas 14756449370562973696 байт / с и другие подобные искаженные выходные данные. Поэтому я думаю, что это, вероятно, сломано. Тем не менее я думаю, что проблемы с буферами ... Я знаю, что Windows делает некоторые необычные вещи с буферизацией TCP и UDP.
Мэтт
Странный. Позже сегодня я, вероятно, получу доступ к хорошей производственной среде 10G и выпустлю iperf3 на этой. Давайте посмотрим, как это происходит.
Евгений Бересовский,
1
Я думаю, вы не понимаете, что -lделает переключатель. Он не устанавливает размер буфера; он устанавливает размер пакета. Это объем данных, которые iperf3 записывает в сокет за один раз и считывает из сокета за один раз. Вы можете установить размер буфера сокета, используя -w. Если вы посмотрите на источник, вы увидите, что он вызывает setsockopt()установку размера буфера сокета, который вы указали после -w.
Андраш Корн
0

Вы полностью упустили самого очевидного виновника - адаптеры, а затем и драйверы (вы утверждаете, что использование разных версий драйверов дает разные результаты).

Попробуйте отключить все возможности разгрузки.

Dani_l
источник
Это не помогло - вопрос обновлен соответственно.
Евгений Бересовский