Я провожу тестирование пропускной способности некоторых радиоустройств с узкими настройками полосы пропускания канала (например, полоса пропускания менее 250 кГц). Во время тестирования iperf3 я заметил, что самая низкая скорость, на которой он когда-либо передавался, несмотря на установку ограничения пропускной способности в командной строке для iperf3, составляла 655 КБ / с (даже если аргумент командной строки был установлен таким образом):
iperf3 -c 10.1.106.82 -u -i 1 -n 10485760 -b 250K
итоговый отчет сервера сообщит о скорости передачи 655 КБ / сек вместо 250 КБ
такое поведение возникает, когда я использую как струйный, так и струйный режим.
trickled, похоже, работает нормально, ограничивая скорость загрузки wget на той же машине. trickled также ограничивает скорость загрузки scp на том же компьютере. есть ли что-то, что я должен сделать, чтобы заставить струйку правильно работать с iperf3? Также есть ли у кого-нибудь объяснение, почему iperf3 не может опускаться ниже 655 КБ / сек, даже если его собственный переключатель командной строки указывает на иное? Я почти уверен, что правильно использую переключатель командной строки для iper3 (и trickle). Пока мой предел iperf3 превышает 655 КБ / сек, ограничение применяется правильно. Проблема в том, что я не могу заставить iperf3 опускаться ниже, поэтому я обратился к trickle, но trickle / trickled, похоже, не работают с iperf3.
edit: Я также пробовал это с trickled, запущенным как на сервере, так и на клиентском компьютере, для которых установлено значение -d 250 и -u 250. Это все равно не имело никакого значения.
Нашел еще один комментарий по суперпользователю. По-видимому:
«trickle работает путем перехвата вызовов для связывания в стандартных библиотечных функциях для передачи TCP - если приложение имеет эти функции, статически связанные во время компиляции, тогда это не может работать».
Я предполагаю, что iperf3 - одна из таких программ, с которой не будет работать.