Я только что установил новую широкополосную связь и хотел проверить ее пропускную способность с помощью iperf3. Однако, похоже, он дает значительно отличающиеся результаты, чем более традиционные тесты скорости.
В то время как онлайн-тесты скорости показывают ожидаемые результаты ~ 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
Чтобы убедиться, что это не проблема с сервером, я обновил лазурную виртуальную машину до размера, который теперь понижает 600 Мбит / с до 1 Гбит с сервера 3.testdebit.info.
В ответ на ответ Джона Локера
Моей главной целью этого вопроса была попытка понять, почему iperf дает такие разные результаты. Я понимаю, что закачки широко распространены, и не слишком озабочены этим (или, по крайней мере, это другой вопрос!)
Серверы Azure, которые я использовал, находились в Северной и Западной Европе (я полагаю, в Амстердаме и Ирландии), и скорость их тестирования в сети достигала 240 Мбит / с.
Однако кажется, что проблема была в многопоточности, я только что перезапустил тест, используя четыре потока вместо одного по умолчанию -
Не могли бы вы сделать мне одолжение и протестировать с iperf 2.0.x вместо iperf3? iperf3 был большой перепиской, которой я не доверяю, и мне интересно, если это еще одно доказательство.
Spiff 8 лет назад
0
Вопрос @Spiff отредактирован с дальнейшими результатами - подключение к общедоступным серверам дало особые результаты! (значения приведены в битах - казалось - но они не складываются)
Michael B 8 лет назад
0
Значения складываются, просто размер файлов обычно указывается в мегабайтах (МиБ), тогда как скорость сети обычно указывается в мегабитах (Мб). Таким образом, вы не можете просто умножить / разделить на 8. Это ближе к 8,2 для Кб / КиБ, 8,4 для Мб / МиБ и 8,6 для Гб / ГиБ.
Spiff 8 лет назад
0
Я не понимаю, как он может получить от 48,6 Мбит до ~ 130 Мбит путем умножения на что-то близкое к восьми! - как ни странно, 12Mbits о скорости загрузки
Michael B 8 лет назад
0
Просто для того, чтобы я мог быть уверен, что правильно следую за вами, когда вы говорите: «Загрузка файла 3,5 ГБ за 210 секунд занимает примерно 130 Мбит», означает ли это «ГБ» - гигабит (1 000 000 000 отдельных бит) или означает ли это GibiBytes (1 073 741 824 8-битных байтов)?
Spiff 8 лет назад
0
И когда вы цитируете это число «3,5 ГБ за 210 секунд = 130 Мбит / с», что это была за загрузка? Какой протокол? С какого сервера? Я спрашиваю, потому что, если это был публичный файл, который может распространяться CDN или кэшироваться прозрачным кэширующим прокси, то, возможно, вы действительно скачивали его с быстрого локального (ish) сервера внутренней сети вашего провайдера, а не с чего-то внешнего для их.
Spiff 8 лет назад
0
Файл был 3500 МБайт ISO, загруженный с серверов Microsoft MSDN - так что вряд ли где-нибудь будет кешироваться - но он работает где-то близко к тому, что ожидается - что-нибудь в шаровом парке в 130 Мбит, я в порядке
Michael B 8 лет назад
0
Кажется, вероятно, будет распространяться CDN. Возможно, вы обнаружите, что соединения вашего провайдера с другими провайдерами (включая магистральных провайдеров) слишком малы или перегружены.
Spiff 8 лет назад
0
CDN, как правило, более ограничены по скорости, чем прямое соединение по кабелю VM. Легко проверить, что IP-адрес сервера не является CDN, по крайней мере, не виртуальной машиной.
John Looker 8 лет назад
0
Средняя скорость загрузки составила 143 Мбит / с, а не 130 Мбит / с. 143Mb / s - это среднее значение для уровня 152Mb, особенно если вы загружаете с сервера Microsoft.
John Looker 8 лет назад
0
Ничего плохого в результатах вашего теста, но сделанные выводы отсутствуют (причины см. В моем ответе). Я бы предложил использовать лучшую методологию тестирования.
John Looker 8 лет назад
0
2 ответа на вопрос
4
Spiff
Beware that IPerf defaults to an "upload" test: The IPerf client (-c) sends TCP data to the IPerf server (-s). It looks like you were running the client on your LAN and connecting to an IPerf server hosted on the public Internet, so you were testing your new broadband connection's upload, not download, speed.
To test its download speed, either reverse which end you invoke as -s/-c, or use -r to specify that you want it to do a "reverse" (download) test after it does the normal test.
Beware that if your LAN machine is behind a NAT or firewall, you may have to open/map/forward a port appropriately for the download test to work.
Хорошая точка зрения! Я забыл об этом - это улучшает положение вещей, хотя и не существенно. до ~ 45Мбит
Michael B 8 лет назад
0
@ Майкл Пожалуйста, обновите свой Вопрос с этими последними результатами. Мне нравится, когда вы вставляете в вывод IPerf, чтобы я мог видеть Mb против MiB для себя.
Spiff 8 лет назад
0
1
John Looker
Хорошие обычные тесты скорости являются многопоточными и создают множество соединений с сервером тестов скорости. Таким образом максимизируя вашу связь с его полным потенциалом.
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, особенно в точках пиринга.
Хотя нет никакого управления трафиком в нисходящем направлении для загрузок, потоковой передачи, игр и т. Д., На уровнях 30 Мб и выше, если ваш трафик классифицируется как P2P, тогда он будет управляться трафиком, а скорость будет снижаться в часы пик.
Причина в том, что пропускная способность восходящего канала очень ограничена, так как она используется сотнями пользователей, и поэтому любая программа, которая может затопить восходящий поток, будет очень плохой для всех пользователей вашего кабеля. Вот почему восходящий поток все еще управляется трафиком.
Вне пикового времени вы должны иметь возможность максимизировать ваше соединение любым удобным для вас способом.
Остерегайтесь тестов, которые используют файлы небольшого размера. Есть ряд тестовых файлов, которые вы можете использовать здесь: http://www.thinkbroadband.com/download/
Ваша загрузка вряд ли будет доставлена по CDN или кэширована внутри сети виртуальных машин. Когда я был на 152Mb, я регулярно скачивал и передавал по 161Mb напрямую с серверов. CDN, как правило, делают доставку медленнее, чем быстрее!
Вам необходимо предоставить дополнительную информацию о вашей стратегии тестирования, чтобы ответить на исходный вопрос.
Похоже, что это была проблема многопоточности, после установки iperf на многопоточность это дало согласованные результаты - см. Исправленный вопрос (и спасибо!)
Michael B 8 лет назад
0
Пожалуйста. Было бы полезно провести сравнение с http://www.thinkbroadband.com/speedtest.html и опубликовать результаты графика. Вы можете обнаружить, что в определенное время дня зеленый тест HTTP x 1 показывает перегрузку, тогда как тест HTTP x 6 максимально.
John Looker 8 лет назад
0
После первоначального замешательства я забыл войти в Azure! (как я получаю загрузку 200 МБ!), они также дают результаты, согласующиеся с результатами, которые я видел [Результаты здесь] (http://tbb.st/1440165921554406455) - Моя первоначальная идея о том, чтобы iperf была последовательной, заключалась в том, что я думал запуска скриптового теста для проверки производительности по часам - что я теперь могу сделать!
Michael B 8 лет назад
0
Зарегистрироваться для Samknows. Делает то же самое, но от маршрутизатора Whitebox и предоставляет инструменты анализа. https://www.samknows.com/
John Looker 8 лет назад
0