iperf3: тест нескольких пользовательских потоков не запускается

Я пытаюсь использовать iperf3, чтобы проверить, где проблемы лежат на клиенте, который использует RDP для подключения к нашему терминальному серверу. Их проблема в том, что окно RDP зависает (щелчки мыши в основном все еще остаются). Иногда помогает минимизация и максимизация окон RDP, в большинстве случаев требуется отключение и повторное подключение.

Поэтому я пытаюсь использовать iperf3 для тестирования протоколов TCP и UDP. Поэтому я попробовал несколько тестов, чтобы увидеть, в чем может быть проблема:

1. iperf3 -c SERVER -u -b 100M -l 500 -t 60 -R --get-server-output --interval 1 --udp

   В результате все запущенные сеансы RDP зависли — моя вина, поскольку у них был только 40-мегабитный контракт с их провайдером. Макс Мбит/с был около 34-36.

2. iperf3 -c SERVER -u -b 35M -l 500 -t 60 -R --get-server-output --interval 1 --udp

   Результат составил около 33% потери пакетов.

   С этим:
   iperf3 -c SERVER -u -b 35M -l 50 -t 60 -R --get-server-output --interval 1 --udp

   У меня было только 2 пакета потерянных в самом начале, а потом 0.

3. Затем я попытался запустить несколько параллельных симуляций с параметрами -P 5. (5 параллельных потоков)

   iperf3 -c SERVER -u -b 35M -l 500 -t 60 -P 5 -R --get-server-output --interval 1 --udp

   Тест начался с того, что сказал стандарт

   Соединение с хост-СЕРВЕРОМ, порт 5201, обратный режим, удаленный хост-СЕРВЕР отправляет

В противном случае я получаю строку за каждую секунду следующим образом:

[  4]  47.00-47.43  sec  3.25MBytes   27.8Mbits/sec   0.085ms   798/3774 (21%)

но потом минуту ничего не происходило. Ни на сервере, ни на клиентском устройстве.

Чтобы проверить, в чем проблема, я уменьшил все возможные переменные и остановился на этом:
iperf3 -c SERVER -u -b 1M -l 50 -t 60 -P 2 -R --get-server-output --interval 1 --udp

Пропускная способность: 1 Мбит
Размер пакета: 50 байт
Параллельные потоки: 2\

И даже с этими низкими требованиями я все равно получил сообщение об установлении соединения, и ничего больше не произошло.

Я недостаточно знаю о сетях, RDP, UPD и iperf3, чтобы точно определить причину этой проблемы. Итак, мой вопрос в первую очередь заключается в том, как интерпретировать это событие?

• У кого-нибудь из вас есть такие проблемы?

Это проблема iperf3? (Не думайте, что это работало с другими клиентами и при предварительном тестировании, работает ли это даже без настройки Terminalserver)

• У вас есть опыт решения такой проблемы?

Если да, то была ли это плохая настройка сети или медленное интернет-соединение от интернет-провайдера?

В настоящее время я предполагаю, что есть проблема с локальной сетью, так как мое понимание сети в противном случае потребовало бы от меня веры в то, что тест размера пакета 35 Мбит / 500 байт менее напряжен, чем тест размера пакета 1 Мбит / 50 байт x2, который кажется очень многое нельзя. Поэтому я считаю, что проблема, скорее всего, в том, что маршрутизатор или коммутатор, который есть у клиента, может быть не в состоянии обрабатывать несколько параллельных потоков.

Но, как вы, вероятно, можете прочитать: я новичок в этом и буду рад любому вашему вкладу, ребята!

Если вам нужна дополнительная информация, просто спросите меня!

РЕДАКТИРОВАТЬ:

Я заменил локальные сетевые коммутаторы, надеясь, что это что-то изменит, поскольку я предполагал, что проблема может заключаться в чем-то локальном. После тестирования проблемы, когда все было сделано, я наткнулся на эти результаты, которые чертовски меня смутили:

iperf3 -c SERVER -u -b 35M -l 500 -t 60 -R --get-server-output --interval 1

-> Потеря пакета 18-20% (немного лучше, чем раньше)

iperf3 -c SERVER -u -b 35M -l 2000 -t 60 -R --get-server-output --interval 1

-> 0.x% потери пакета.

iperf3 -c SERVER -u -b 35M -l 5 -t 60 -R --get-server-output --interval 1

-> Только сообщения о получении посылок не по порядку

Я также протестировал iperf с TCP-протоколом, чего раньше не делал, потому что изменение всех подключений к TCP еще больше ухудшило ситуацию. Но когда я это сделал, это работало даже с несколькими потоками одновременно: iperf3 -c [server IP] -b 35M -l 1M -P 5 -t 60 -R —get-server-output —interval 1

Может быть, чтобы сделать вопрос более конкретным: что может ухудшить работу сеансов UPD RDP, если мы перераспределим пропускную способность — что я сделал за последние несколько дней, чтобы уменьшить проблему, но теперь я думаю, что это могло усугубить ее? (надо спросить об этом завтра более конкретно)

Я не ответил на вопрос, но я хотя бы решил проблему с RDP-дисконнектами:

Основываясь на результатах тестов, я вручную увеличил пропускную способность, используемую для RDP, до 10 Мбит / локальная сеть вместо того, чтобы снижать ее или оставлять на автоматическом уровне. Это решило проблему — до сих пор: вместо того, чтобы окна RDP зависали несколько раз в час, сегодня этого не происходило большую часть дня.

Тем не менее, вопрос все еще остается: с какой стати тест с несколькими пользователями UPD (-P 5) не начинается после установления соединения. Так что, если кто-то может помочь с этим, я все равно ценю это!