iperf3 udp тихий разрыв со стороны отправителя

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

Сервер iperf3 работает на машине Linux. Я запускаю трафик с помощью этой команды на стороне клиента со следующими флагами: опция -R, чтобы позволить серверу отправлять клиенту: iperf3 -c 32.0.161.84 -u -l 1360 -b 550M -P 8 -w 16M -R -т 3000

В большинстве случаев все работает как положено, я получаю около 4 Гбит/с. Но в некоторых случаях, например, 1-2 раза из 10 итераций, я получаю более низкую пропускную способность, чем ожидалось. Насколько ниже, кажется случайным, может быть 2 Гбит/с или 3 или 3,5. Когда я получаю сценарий с низкой пропускной способностью, она обычно остается низкой в ​​течение нескольких минут. Иногда через пару минут он мог сам восстановиться до максимальной скорости, а иногда оставался низким дольше. Когда я получаю этот сценарий с низкой пропускной способностью, я могу получить сценарий с хорошей пропускной способностью, если остановлю трафик и запущу снова, и в этом случае клиентская сторона получила новый IP-адрес, так как он динамически назначается клиенту на каждой итерации.

Глядя на распечатки со стороны отправляющего сервера, он говорит, что отправляет 8x550M, и я также проверил с помощью ifstat, который также показывает, что он отправляет 4400 Мбит/с.

Все еще принимающая сторона получает более низкую скорость.

Зеркальное отображение карты Ethernet машины, на которой работает клиент iperf (отправляющая сторона), в wirehark показывает, что время от времени возникает тихий промежуток в 10,8 мс, что может объяснить более низкую скорость приема.

захват wireshark

В этом примере с wirehark трафик составляет 4,4 Гбит/с, а затем внезапно появляется пауза молчания на 10,8 мс, и мы теряем 4486 ip-кадров с 1360 байтами. Это может объяснить, почему на какое-то время трафик упал до 3 Гбит/с.

Кто-нибудь знает, почему это происходит, и является ли это известной проблемой, которая может быть устранена в более поздних версиях, 3.8 или 3.9? Любой дополнительный флаг может быть полезен, чтобы избежать этого сценария? Я пытался запустить сервер на другом компьютере с Linux, но возникла та же проблема, поэтому я не думаю, что это проблема на самом компьютере.

BR Никлас


person Nicke    schedule 12.05.2021    source источник


Ответы (1)


Мы изменили метод ведения журнала на то, что называется net-sniff, и тогда мы больше не можем видеть разрыв, когда происходит более низкая пропускная способность. Таким образом, пробел, о котором я упоминал изначально, не был настоящим пробелом, скорее всего, это ошибка в журналировании. Таким образом, мы считаем, что iperf3 работает должным образом, и думаем, что более низкая пропускная способность связана с чем-то в сети.

person Nicke    schedule 18.05.2021