Iperf дает неверные результаты
Я только что установил новую широкополосную связь и хотел проверить ее пропускную способность с помощью iperf3. Однако, похоже, он дает значительно отличающиеся результаты, чем более обычные тесты скорости.
E:\tmp> iperf3 -c 3.testdebit.info
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.01 sec 13.1 MBytes 11.0 Mbits/sec sender
[ 4] 0.00-10.01 sec 13.1 MBytes 11.0 Mbits/sec receiver
В то время как онлайн-тесты скорости показывают ожидаемые результаты ~150 Мбит
3.testdebit.info был протестирован с лазурного и постоянно около 330 Мбит (хотя кто знает, что это значит больше!)
Я пробовал различные серверы, в том числе Linux-сервер, размещенный на Azure, который доставляет ~100 Мбит на другой Azure-сервер. Это также было выполнено на порте 80, чтобы исключить любое регулирование ISP. Все эти результаты сопоставимы.
Загрузка файла 3,5 ГБ за 210 секунд, работает примерно до 130 Мбит
Может ли кто-нибудь пролить свет на то, почему iperf3 может быть таким низким (или я действительно тупой и читаю что-то не так!)
Все они находятся на одном компьютере, через Ethernet, поэтому никакие беспроводные устройства не мешают.
отредактировано, чтобы добавить
Выполнение одного и того же теста с iperf2 (на клиенте Windows (iPerf 2.0.5-3) и Ubuntu (версия iperf 2.0.5)) дает эти результаты
E:\tmp\iperf2> iperf -c <hidden>.cloudapp.net -p 5201
------------------------------------------------------------
Client connecting to <hidden>.cloudapp.net, TCP port 5201
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.2 port 51816 connected with <hidden> port 5201
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 12.1 MBytes 10.0 Mbits/sec
То же самое выполняется с NAS на основе Linux
Nas:~# iperf3 -c 3.testdebit.info
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 14.5 MBytes 12.2 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 14.5 MBytes 12.2 Mbits/sec receiver
И с флагом -R
E:\tmp> iperf3 -c 3.testdebit.info -R
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 58.0 MBytes 48.6 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 57.0 MBytes 47.8 Mbits/sec receiver
Чтобы убедиться, что это не проблема с сервером, я обновил лазурную виртуальную машину до размера, который теперь поднимает 600 Мбит вверх / 1 Гбит с сервера 3.testdebit.info.
В ответ на ответ Джона Локера
Моей главной целью этого вопроса была попытка понять, почему iperf дает такие разные результаты. Я понимаю, что закачки широко распространены, и не слишком озабочены этим (или, по крайней мере, это другой вопрос!)
Используемые мной серверы Azure находились в Северной и Западной Европе (я полагаю, в Амстердаме и Ирландии), и скорость их тестирования в сети достигала 240 Мбит / с.
Тем не менее, похоже, что многопоточность была проблемой, я просто перезапустил тест, используя четыре потока вместо одного по умолчанию -
E:\tmp>iperf3 -c 3.testdebit.info -R -P 5
Connecting to host 3.testdebit.info, port 5201
Reverse mode, remote host 3.testdebit.info is sending
- - - - - - - - - - - - - - - - - - - - - - - - -
[SUM] 0.00-10.00 sec 195 MBytes 163 Mbits/sec 50 sender
[SUM] 0.00-10.00 sec 190 MBytes 160 Mbits/sec receiver
2 ответа
- Хорошие обычные тесты скорости являются многопоточными и создают множество соединений с сервером тестов скорости. Таким образом максимизируя вашу связь с его полным потенциалом.
http://www.thinkbroadband.com/faq/sections/flash-speed-test.html
iPerf3, по-видимому, создает только два соединения (с использованием параметров по умолчанию), которых может быть недостаточно для обеспечения максимальной широкополосной связи в 152 МБ, особенно когда возникает перегрузка.
Ваш тест загрузки также предлагает многопоточные соединения.
Загрузка файла 3,5 ГБ за 210 секунд, работает примерно до 130 Мбит
Однако ваш расчет неверен.
((3,5 ГБ x 8 бит x1024x1024x1024) / 210 с) / 1000000 Мбит = 143 Мбит / с в среднем.
Средняя скорость 143 Мбит / с подходит для загрузки на уровне 152 МБ.
В то время как уровень 152 Мбит / с будет максимальным при скорости пакетной загрузки 161 Мбит / с (ваш модем перепрофилирован, чтобы гарантировать скорости), средние скорости часто будут немного ниже из-за нескольких факторов.
- Ограничение скорости сервером.
- Окну приема TCP требуется время для увеличения скорости.
- Цикл запроса-предоставления кабельного модема.
- Заторы на узле. Вы делитесь своим кабельным соединением (и, следовательно, вашими нисходящими каналами) с сотнями других людей. Каналы нисходящего потока 8 x 256 QAM, которые вы заблокировали на кабельном модеме, имеют максимальную полезную полосу пропускания в 400 МБ, исходящую от узла. Эти данные передаются между вами и всеми другими пользователями вашего кабеля по тем же каналам, что и вы. Когда другие пользователи используют свое соединение во время загрузки, скорость, естественно, будет немного отличаться.
- Пробки на трассе.
- Заторы на сервере.
- Любая потеря пакета и повторная передача.
Восходящая полоса пропускания сильно зависит от других пользователей, подключенных к вашему кабелю.
Если у вас заблокированы 2 x 16 восходящих каналов QAM, то вы делитесь 2 x 17Mb = 34Mb со многими другими пользователями. Если у вас заблокированы 2 x 64 восходящих канала QAM, то вы совместно используете 2 x 27 МБ = 54 МБ со многими другими пользователями.
- На больших расстояниях задержка станет фактором скорости, которую вы можете достичь.
Вы не указали, какой сервер Azure вы используете, будь то Великобритания, Европа или Америка.
Ваш сервер iPerf3 находится во Франции и может или не может маршрутизировать через LINX, в зависимости от вашего местоположения. Перегрузка на маршруте иногда может быть проблемой, когда она покидает сеть VM, особенно в точках пиринга.
- Нестандартные порты часто будут рассматриваться как трафик P2P. http://www.thinkbroadband.com/faq/sections/flash-speed-test.html
Хотя нет никакого управления трафиком в нисходящем направлении для загрузок, потоковой передачи, игр и т. Д., На уровнях 30 Мб и выше, если ваш трафик классифицируется как P2P, тогда он будет управляться трафиком, а скорость будет снижаться в часы пик.
Причина в том, что пропускная способность восходящего канала очень ограничена, так как она используется сотнями пользователей, и поэтому любая программа, которая может затопить восходящий поток, будет очень плохой для всех пользователей вашего кабеля. Вот почему восходящий поток все еще управляется трафиком.
Вне пикового времени вы должны иметь возможность максимизировать ваше соединение любым удобным для вас способом.
Остерегайтесь тестов, которые используют файлы небольшого размера. Есть ряд тестовых файлов, которые вы можете использовать здесь: http://www.thinkbroadband.com/download/
Ваша загрузка вряд ли будет доставлена по CDN или кэширована внутри сети виртуальных машин. Когда я был на 152Mb, я регулярно скачивал и передавал по 161Mb прямо с серверов. CDN, как правило, делают доставку медленнее, чем быстрее!
Вам необходимо предоставить дополнительную информацию о вашей стратегии тестирования, чтобы ответить на исходный вопрос.
Помните, что по умолчанию IPerf является тестом "загрузки": клиент IPerf (-c) отправляет данные TCP на сервер IPerf (-s). Похоже, вы работали с клиентом в локальной сети и подключались к серверу IPerf, размещенному в общедоступном Интернете, поэтому вы тестировали скорость загрузки, а не загрузки нового широкополосного соединения.
Чтобы проверить скорость загрузки, либо откройте, какой конец вы вызываете как -s/-cили используйте -r указать, что вы хотите, чтобы он выполнял "обратный" (загрузочный) тест после того, как он выполнит обычный тест.
Помните, что если ваша локальная сеть находится за NAT или межсетевым экраном, вам может потребоваться открыть / отобразить / переадресовать порт соответствующим образом, чтобы тест загрузки работал.