Почему несоответствие между Speedtest и Wget?

18

Мой клиент жалуется на низкую скорость интернета. При измерении с Speedtest.net скорости приемлемы. Периодические измеренные загрузки составляют от 10% до 30% от номинальной скорости. Я не могу этого объяснить.

Некоторый фон. Проблемное соединение на одном из тех солнечных Карибских островов, где быстрый интернет не самый большой актив. В последнее время скорость интернета стала приличной, до 200 Мбит / с. Но пинг туда и обратно в (скажем) Амстердаме составляет около 180 мс.

Заказчик имеет оптоволоконную связь 100 Мбит / с. При проведении speedtest на компьютере под управлением Windows (speedtest.net) для ISP CO мы получаем 95 Мбит / с. При использовании того же теста скорости для Амстердама мы достигаем 60-70 Мбит / с. Полностью приемлемо

Некоторое время назад я установил RasPi, который периодически получает файл с одного из моих серверов в Амстердаме. В центре обработки данных, который напрямую связан с AMS-IX. Используя эту команду:

wget -O /dev/null --report-speed=bits http://aserv.example.net/~myuser/links/M77232917.txt

Файл .txt имеет размер 23 МБ. (На самом деле это самый большой Mersenne Prime, 23e6 цифр)

Когда я загружаю этот файл в проблемную сеть, wget сообщает об этом:

dev/null 100%[====================================================================>]  22.81M  11.6Mb/s   in 17s    

2019-02-08 14:27:55 (11.2 Mb/s) - ‘/dev/null’ saved [23923322/23923322]

То есть в то же время speedtest.net сообщает о 60-70 Мбит / с.

Я знаю, что у Raspi есть свои ограничения. Но эта скорость сильно варьируется. Один раз RasPi сообщает об этом 11 Мбит / с, в следующий раз 22 Мбит / с. Но иногда до 1,5 Мбит / с.

Когда я провожу этот тест на действительно мощном ноутбуке, максимальные скорости несколько выше (до 30 Мбит / с), но также показывают те же самые минимумы. Таким образом, это указывает на ограничение RasPi на верхней стороне, но не на 10 Мбит / с на нижней стороне.

Я выполнил точно такую же команду с сервера в Мюнхене, Германия, в центре обработки данных. Скорость 96 Мбит / с.

Тогда от потребителя 100 Мбит / с волоконно-оптической связи в Нидерландах: 65 Мбит / с.

Затем в моем доме, который имеет номинальную скорость 10 Мбит / с ADSL. Speedtest показывает 10 Мбит / с. Wget дает 8,5 Мбит / с. Который равен в моей книге.

Это исключает любые ограничения на сервере, который выступает в качестве хоста для загрузки файла.

Я не ожидаю, что кто-либо может указать причину медлительности соединения в помещении клиента. Но кто-нибудь может объяснить несоответствие между speedtest.net и wget?

Есть ли что-то, что тестирование скорости игнорирует, или оно измеряет только пики? Или на wget серьёзно влияют долгие пинговые времена?

Я чувствую, что тест wget дает реальную эффективную скорость, в то время как speedtest в основном показывает объявленную скорость.

— Ханс Линкельс
источник

Еще один способ проверить скорость - ssh personal-server cat /dev/zero | pv > /dev/nullна персональном сервере, который, как вы знаете, не ограничен в скорости, должен быть медленнее ожидаемой скорости.

— JoL

Я снял твой вопрос. И это звучит так, как будто у вас большая пропускная способность и, возможно, значительный сценарий задержки туда-обратно, также известный как «длинная полная сеть». Я лично сталкивался с подобными вещами и решил их, открыв множество соединений (я использовал rsync). Можете ли вы попробовать открыть много экземпляров wget (попробуйте 5, 10, 20)? Страница Википедии: продукт задержки полосы пропускания.

— Тревор Бойд Смит

Wget сообщает в байтах по умолчанию: [james @ lamia root] $ wget -O / dev / null 10.32.48.1/t1 / dev / null 100% [================== ====>] 100,00M 112 МБ / с за 0,9 с [james @ lamia root] $ wget --report-speed = биты -O / dev / null 10.32.48.1/t1 / dev / null 100% [=== ==================>] 100.00M 932Mb / s за 0.9s

— Джеймс

Попробуйте запустить сервер iperf для tcp и секунду для udp на компьютере с DC. Затем, в рамках задания cron, вызовите тест у своего клиента и посмотрите, как скорости сравниваются с http get.

— Кригги

Что это за файл? Это сжимаемо, и сервер поддерживает сжатие http? Хотя вы не можете исправить проблемы с пропускной способностью, вы можете уменьшить размер файла.

— Салман А

16

В дополнение к другим опубликованным причинам TCP-соединения плохо работают с большими файлами, когда продукт с задержкой пропускной способности становится большим.

Как в случае быстрой связи с островом.

Смотрите запись в Википедии о настройке TCP .

Таким образом, Speedtest может вывести небольшой файл через соединение со скоростью 95 МБ / с, но wgetможет получить только 10 МБ / с для файла с 20 МБ.

— Эндрю Хенле
источник

2

Это новое знание для меня. Очень хорошо. Действительно, продукт с задержкой полосы пропускания высок (2,25 МБ, если я правильно рассчитал). Быстрый просмотр показал, что по умолчанию используется буфер размером 87 КБ и максимум 3,5 МБ. (Я предполагаю, Байт не биты). Я должен углубиться в это, чтобы лучше оценить это. Если в сочетании speedtest загружает много небольших файлов и записывает максимальную скорость, это многое объясняет.

— Ганс Линкельс

21

Интернет-провайдеры часто отдают приоритет трафику speedtest.net, чтобы они могли похвастаться скоростью своих соединений, хотя в действительности они не обеспечивают такой большой пропускной способности. Они прекрасно знают, что большинство пользователей будут проверять этот сайт только для подтверждения.

Вы также должны помнить, что скорость передачи зависит как от клиента, так и от сервера. В современном мире большинство серверов работают так или иначе.

Наконец, бессмысленно ожидать стабильной пропускной способности для зарубежных соединений. Там просто нет такой вещи. Он должен пройти через бесконечное число переключателей, волокон, центров обработки данных, чтобы достичь конечного местоположения. И все, что нужно, это только одна движущаяся часть, чтобы замедлиться.

— bviktor
источник

Я понимаю ваши заявления, за исключением регулирования на стороне сервера. Это мой собственный сервер, и когда клиент находится в другом центре обработки данных (около 1200 км), скорость постоянно составляет 95 Мбит / с. Даже если клиент подключен к потребителю со скоростью 100 МБ, он составляет 65 Мбит / с.

— Ганс Линкельс

9

Можете ли вы документ, который вы утверждаете? «Интернет-провайдеры часто отдают приоритет трафику для speedtest.net»

— Солей

1

@Soleil Не нужно слишком много гуглить

— MonkeyZeus

6

Интернет-провайдер, который определяет приоритетность скоростного трафика, так же вероятен, как и тесты на фальшивые выбросы крупного производителя автомобилей.

— Бармар

3

В свое время я однажды смог «исправить» заикание потока Суперкубка, многократно отправляя трафик на speedtest.net с Raspberry Pi. Похоже, они расставили приоритеты для всего моего соединения, пока присутствовал скоростной трафик - разница между днем и ночью. Это не много доказательств того, что интернет-провайдеры делают неясные вещи, но это нечто

— Отменить

7

wgetдать хороший практический показатель скорости. Тесты Speedtest, вероятно, включают в себя вид параллелизма, который может объяснить большее число.

Для хорошего теста средней скорости я думаю, что время загрузки должно быть не менее 90-120 секунд (чтобы получить хороший средний показатель)

— Ромео Нинов
источник

Я работаю над установкой более мощного компьютера для ведения журналов и увеличения размера файла.

— Ганс Линкельс

Можете ли вы развить «вид параллелизма»? Я не вижу никакой причины / причины, поскольку существует априори 1 соединение.

— Солей

1

@ Солей, ИМХО они скачивают несколько файлов, а не только один. Вы можете проверить это, запустив несколько раз wgetи суммировав скорость

— Ромео Нинов

1

Я мог бы распараллелить свое измерение, но в чем выгода? Я уже продемонстрировал, что другие клиенты достигают полной скорости. Разница в том, что проблемное соединение имеет задержку 180 мс. Быстрые соединения <10 мс. Параллельно уменьшит эффекты латентности? Просто спрашиваю.

— Ханс Линкельс

1

@RomeoNinov Я проверил, такого параллелизма нет (speedtest.net). Один файл на загрузку и один на загрузку ([1-2] МБ каждый).

— Солей

3

Одной из причин может быть то, что часто максимальная скорость не может быть достигнута только одним TCP-соединением.

Speedtest.net недавно представил единый режим подключения. Попробуйте это и посмотрите, если это имеет значение.

Затем для загрузки используйте, например, aria2 с параметрами, чтобы использовать несколько соединений и сравнить. напримерaria2c -d /dev -o null --allow-overwrite=true --file-allocation=none --max-connection-per-server=8 --min-split-size=1M http://aserv.example.net/~myuser/links/M77232917.txt

— Josef
источник

2

Используйте Fast.com Internet Speed Test , это тест скорости на основе Netflix, означающий, что интернет-провайдеры не могут отличить его от самого Netflix.

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

Интернет-провайдеры часто повышают скорость в зависимости от домена, к которому кто-то подключается, если это тест скорости или используется порт 8080. Принимая во внимание, что Netflix использует порт 80, более медленный порт, когда ему отдается приоритет.

— Джонатан
источник

1

«это означает, что интернет-провайдер не может отличить его от самого Netflix». Это неверно, интернет-провайдер может определенно видеть как запрос DNS, так и SNI на HTTPS-соединении.

— Кевин

@Kevin fast.com связывается с серверами netflix для загрузки, то есть эмулирует видео с самого netflix. Хотя я предоставлю вам, что интернет-провайдеры могут поймать тот факт, что подключение к этому конкретному сайту, который впоследствии связывается с серверами на основе Netflix, требует приоритезации, подобной speedtest.net

— Джонатан

Это не совсем ракетостроение. Все, что им нужно сделать, это отменить Netflix в течение нескольких минут или часов после того, как они увидят соединение fast.com. Плюсом, конечно же, является то, что вы можете зайти на fast.com, чтобы получить контроль над собой, затем закрыть вкладку и посмотреть Netflix по-настоящему.

— Кевин

Лично я подозреваю, что это компьютерная наука или, по крайней мере, связанная с ней, а не ракетостроение. Похоже, что некоторые из крупных интернет-провайдеров (например, Белл) за последние несколько лет не попали на fast.com. В любом случае, запуск сценария на вашем компьютере, который подключается к fast.com, для увеличения скорости загрузки, если регулирование достаточно плохое, будет жизнеспособным.

— Джонатан

0

Это только я или никто не заметил, что он сказал Мбит / с и список команд wget "МБ / с".

60 Мбит / с и фактически получение 11.2 Мбит / с - это нормально.

Мбит / с и МБ / с - это две разные скорости.

«Мегабит на 1/8 больше, чем мегабайт, а это означает, что для загрузки файла размером 1 МБ за 1 секунду вам потребуется подключение 8 Мбит / с.» Так что 11 МБх8 = 88 Мбит / с ... 11,2 МБ на самом деле хорошо для создания отчетов о подключении 60-70mbps.

Люди, имеющие память, теряют это. Вы никогда не получите 70 Мбит / с со скоростью 70 Мбит / с

— бла чесли
источник

Выходное значение wgetравно Мбит / с, что переводится в Мегабит / с . МБ / с будет переводиться в мегабайты / с . Просто запустите вашу собственную wgetкоманду и проверьте результат.

— Томас

1

@james: Да, по умолчанию, но в OP wgetкоманда указывает, --report-speed=bitsкакие результаты в Mb/sкакой Mbit/s. Бег без --report-speed=bitsдает, MB/sчто переводится как MByte/s. Обратите внимание на bи B.

— Томас