Чому невідповідність між Speedtest та Wget?

18

Мій клієнт скаржиться на низькі швидкості Інтернету. При вимірюванні за допомогою Speedtest.net швидкості прийнятні. Періодичні вимірювані завантаження становлять від 10% до 30% від номінальної швидкості. Я не можу цього пояснити.

Якесь тло. Проблемний зв'язок є на одному з тих сонячних островів Карибського басейну, де швидкий Інтернет не є найбільшим надбанням. Останнім часом швидкість Інтернету стала пристойною, до 200 Мбіт / с. Але пішохідна поїздка до (скажімо) Амстердама становить близько 180 мс.

Клієнт має волоконний зв’язок 100 Мбіт / с. При проведенні швидкості на машині 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 повідомляє про це 11 Мбіт / с, наступний раз - 22 Мбіт / с. Але іноді до 1,5 Мбіт / с.

Коли я роблю цей тест із справді потужним ноутбуком, максимальна швидкість дещо вища (до 30 Мбіт / с), але також показує ті самі мінімуми. Отже, це вказує на обмеження RasPi на високій стороні, але не на 10 Мбіт / с на нижній стороні.

Я випустив абсолютно таку ж команду з сервера в мюнхені, Німеччина, в центрі обробки даних. Швидкість 96 Мбіт / с.

Тоді від споживчого з'єднання 100 Мбіт / с в Голландії: 65 Мбіт / с.

Потім, у мене вдома, який має номінальну ADSL 10 Мбіт / с. Швидкість показує 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.00 М 112 МБ / с за 0,9 с [james @ lamia root] $ wget --report-speed = біт -O / dev / null 10.32.48.1/t1 / dev / null 100% [=== ==================>] 100.00m 932Mb / с в 0.9s

— Джеймсу

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

— Criggie

Що це за файл? Це стисливо і сервер підтримує стиснення http? Хоча ви не можете вирішити проблеми із пропускною здатністю, можливо, ви зможете зменшити файл.

— Салман

16

На додаток до інших розміщених причин, TCP-з'єднання не працюють добре з великими файлами, коли продукт із затримкою пропускної здатності стає великим.

Як на іншому швидкому сполученні з островом.

Дивіться запис Вікіпедії про налаштування TCP .

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

— Ендрю Генле
джерело

2

Це для мене нові знання. Дуже добре. Дійсно, продукт із затримкою пропускної здатності великий (2,25 Мб, якщо я правильно розрахував). Швидкий огляд показав буфер за замовчуванням 87 кБ та максимум 3,5 МБ. (Я припускаю, що Байт не є бітами). Я мушу глибше зануритися в це, щоб краще оцінити це. Якщо в поєднанні speedtest завантажує багато невеликих файлів і записує максимальну швидкість на цьому, це багато що пояснює.

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

21

Провайдери часто надають пріоритет трафіку до speedtest.net, щоб вони могли похвалитися швидкістю їх з'єднань, а насправді вони не забезпечують такої величини пропускної здатності. Вони прекрасно знають, що більшість користувачів перевірять цей сайт лише для підтвердження.

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

Нарешті, безглуздо очікувати стабільної пропускної здатності для закордонних з'єднань. Просто такого немає. Для досягнення остаточного місця необхідно пройти нескінченну кількість комутаторів, волокон, центрів обробки даних. Все, що потрібно, - це лише одна рухома частина, щоб гальмувати.

— бвіктор
джерело

Я розумію ваші висловлювання, за винятком того, що ви заглушили на стороні сервера. Це мій власний сервер, і коли клієнт перебуває в іншому центрі обробки даних (приблизно в 1200 км), швидкість стабільно становить 95 Мбіт / с. Навіть якщо клієнт знаходиться на 100 Мб споживчому з'єднанні, це 65 Мбіт / с.

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

9

Чи можете ви документувати претензію? "Інтернет-провайдери часто

— Soleil

1

@Soleil Не взяв занадто багато Гуглінг

— MonkeyZeus

6

Провайдер, що надає пріоритет швидкісному трафіку, напевно, як і великий виробник автомобілів, підробляє випробування на викиди.

— Бармар

3

Анекдотично мені одного разу вдалося «виправити» заїкаючий потік Super Bowl, надсилаючи трафік на speedtest.net кілька разів із Raspberry Pi. Здавалося, вони надавали пріоритет усьому моєму зв’язку до тих пір, поки був швидкий рух транспорту - різниця в ніч і день. Це не багато доказів того, що провайдери роблять тіньові речі, але це щось.

— Скасувати

7

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

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

— Ромео Нінов
джерело

Я працюю над встановленням більш потужного комп'ютера реєстрації та збільшення розміру файлу.

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

Чи можете ви розвинути "вид паралелізму"? Я не бачу жодного способу / причини, оскільки є апріорний 1 зв'язок.

— Солей

1

@Soleil, IMHO вони завантажують декілька файлів, не один. Ви можете перевірити його, пробігшись кількома 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

— Йосиф
джерело

2

Використовуйте тест швидкості Інтернету Fast.com , це тест на швидкості на основі Netflix, тобто його не можна диференціювати через Інтернет-провайдери від самого Netflix.

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

Інтернет-провайдери часто збільшують швидкість на основі домену, до якого хтось підключається, якщо це тест швидкості або використовується порт 8080. В той час як Netflix використовує порт 80, більш повільний порт, коли йому надається пріоритет.

— Джонатан
джерело

1

"Це означає, що його не можна відрізнити Інтернет-провайдером від самого Netflix" - Це неправда, ISP може точно бачити і запит DNS, і SNI на HTTPS-з'єднанні.

— Кевін

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

— Джонатан

Це не зовсім ракетна наука. Все, що їм потрібно зробити, - це скасувати Netflix протягом декількох хвилин або годин після того, як вони побачать зв’язок fast.com. Переважно, звичайно, ви можете зайти на fast.com, щоб отримати невпевненість у собі, а потім закрити вкладку і подивитися реально Netflix.

— Кевін

Особисто я підозрюю, що це інформатика чи принаймні пов'язана з нею, а не ракетна наука. Здається, деякі більші Інтернет-провайдери (наприклад, Bell) не потрапили на fast.com за останні кілька років. У будь-якому випадку запуск сценарію на комп’ютері, який підключається до fast.com, для того, щоб швидко збільшувати швидкість завантаження, якщо дроселювання досить погано, було б життєздатним.

— Джонатан

0

Це тільки я або ніхто не помітив, він сказав Мбіт / с і список команд wget "MB / s".

60 Мбіт / с і фактично отримувати 11,2 Мбіт - це нормально.

Мбіт / с і МБ / с - це дві різні швидкості.

"Мегабіт на 1/8 такий же великий, як Мегабайт 60-70 мбіт / с.

Люди, які мають пам'ять, втрачають це. Ви ніколи не отримаєте 70 Мб / с зі швидкістю швидкістю 70 Мбіт / с

— бла Чеслі
джерело

Вихід wgetє Мб / с , який переводить до мегабіт / с . Мб / с перекладається на MegaBytes / s . Просто запустіть власну wgetкоманду і перевірте результат.

— Томас

1

@james: Так за замовчуванням, але в wgetкоманді OP команда включає, --report-speed=bitsякі результати в Mb/sяких є Mbit/s. Запуск без --report-speed=bitsподачі, MB/sщо перекладається на MByte/s. Зверніть увагу на bі B.

— Томас