Екстремальна втрата пакету UDP при 300 Мбіт (14%), але ретрансляція TCP> 800 Мбіт без огляду


11

У мене є Linux-ящик, який я використовую як iperf3клієнт, тестуючи 2 однаково обладнані серверні коробки Windows 2012 R2 з адаптерами Broadcom BCM5721, 1 Гбіт (2 порти, але для тестування використовується лише 1). Всі машини підключені за допомогою одного комутатора 1 Гбіт.

Тестування 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 (апаратне? Драйвер? Налаштування?)?
  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 КБ)

8 КБ ?? це зовсім небагато, коли немає контролю заторів.

наприклад на стороні сервера.

~$ 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 (вище 10Gbps). Симптом полягає в тому, що при будь-якому конкретному виконанні iperf3 приймач повідомляє про рівень втрат близько 20%, незалежно від параметра -b, що використовується на стороні клієнта. Ця проблема, як видається, не є специфічною для iperf3, і може бути пов'язана з розміщенням процесу iperf3 в процесорі та його відношенням до вхідного NIC. В деяких випадках цю проблему можна усунути за допомогою відповідного використання опції спорідненості CPU (-A). (Випуск №55)

Ви використовуєте більш повільний NIC, але мені цікаво, чи це пов'язано.


Так, а щодо втрати пакету, я покажу, як це може статися. оновлення відповіді.
Мет

Дякую Метт, щойно побачив ваше оновлення. Мій iperf (як на сервері Windows, так і на клієнті Linux) - версія 2.0.5. Що твоє?
Євген Бересовський

Так само. Насправді, коли я встановлюю цільову пропускну здатність в 1G, я отримую частоти пропускної здатності bonkas 14756449370562973696 байт / с та інші такі пошкоджені виводи. Тому я думаю, що це, ймовірно, зламано. І все-таки я думаю, що проблеми буфери ... Я знаю, що Windows робить деякі незвичайні речі з буферизацією TCP та UDP.
Метт

Дивно. Пізніше сьогодні я, мабуть, отримаю доступ до хорошого виробничого середовища 10G, і я накладу на нього iperf3. Подивимось, як це йде.
Євген Бересовський

1
Я думаю, ви неправильно розумієте, що -lробить перемикач. Він не встановлює розмір буфера; він встановлює розмір пакету. Це обсяг даних, який iperf3 запише в сокет за один раз, і прочитає з сокета за один раз. Ви можете встановити розмір буфера сокета за допомогою -w. Якщо ви подивитесь на джерело, ви побачите, що він вимагає setsockopt()встановити розмір буфера сокета на те, що ви вказали після -w.
Андрас Корн

0

Ви повністю пропустили найочевиднішого винуватця - адаптери, а потім і драйвери (ви заявляєте, що використання іншої версії драйверів дає різні результати).

Спробуйте вимкнути всі можливості вивантаження.


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