Dlaczego rozbieżność między Speedtest a Wget?

18

Mój klient skarży się na niskie prędkości internetu. W przypadku pomiaru za pomocą Speedtest.net prędkości są dopuszczalne. Okresowe pomiary pobierania wynoszą od 10% do 30% prędkości nominalnej. Nie umiem tego wytłumaczyć.

Trochę tła. Problematyczne połączenie występuje na jednej z tych słonecznych wysp karaibskich, gdzie szybki Internet nie jest największym atutem. Ostatnio prędkości Internetu stały się przyzwoite, nawet do 200 Mbps. Ale ping w obie strony do (powiedzmy) Amsterdamu to około 180 ms.

Klient ma połączenie światłowodowe 100 Mb / s. Podczas przeprowadzania testu szybkości na komputerze z systemem Windows (speedtest.net) do dostawcy usług internetowych CO uzyskujemy 95 Mb / s. Korzystając z tego samego testu prędkości do Amsterdamu, osiągamy 60-70 Mbs. W pełni do zaakceptowania.

Jakiś czas temu zainstalowałem RasPi, który okresowo pobiera plik z jednego z moich serwerów w Amsterdamie. W centrum danych, które jest bezpośrednio podłączone do AMS-IX. Za pomocą tego polecenia:

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

Plik .txt ma 23 MB bajtów liczb. (W rzeczywistości jest to jedna, ale największa Mersenne Prime, 23e6 cyfr)

Kiedy pobieram ten plik do problematycznej sieci, wget zgłasza to:

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]

To jest w tym samym czasie raporty speedtest.net 60-70 Mbps.

Wiem, że Raspi ma swoje ograniczenia. Ale ta prędkość jest bardzo zróżnicowana. Raz RasPi zgłasza to 11 Mbps, następnym razem 22 Mbps. Ale czasami tak niskie, jak 1,5 Mbps.

Kiedy robię ten test z naprawdę potężnym laptopem, najwyższe prędkości są nieco wyższe (do 30 Mb / s), ale wykazują te same niskie wartości. Oznacza to ograniczenie RasPi po stronie wysokiej, ale nie 10 Mbps po stronie niskiej.

Wydałem dokładnie to samo polecenie z serwera w Monachium w Niemczech w centrum danych. Prędkość 96 Mbps.

Następnie od konsumenta połączenie światłowodowe 100 Mb / s w Holandii: 65 Mb / s.

Następnie w moim domu, który ma nominalną prędkość 10 Mb / s ADSL. Speedtest pokazuje 10 Mb / s. Wget daje 8,5 Mbps. Co jest równe w mojej książce.

Wyklucza to jakiekolwiek ograniczenia na serwerze, który działa jako host dla pobierania plików.

Nie oczekuję, że ktoś może wskazać przyczynę powolności połączenia w siedzibie klienta. Ale czy ktoś może wyjaśnić rozbieżność między speedtest.net a wgetem?

Czy jest coś, co speedtest ignoruje, czy mierzy tylko piki? A może długi czas pingowania ma poważny wpływ na wget?

Uważam, że test wget daje rzeczywistą, efektywną prędkość, podczas gdy speedtest ma głównie na celu pokazanie reklamowanej prędkości.

— Hans Linkels
źródło

Innym sposobem sprawdzenia prędkości jest zrobienie tego ssh personal-server cat /dev/zero | pv > /dev/nullna osobistym serwerze, o którym wiesz, że nie jest ograniczona stawka, aby być niższa niż oczekiwana prędkość.

— JoL

Przejrzałem twoje pytanie. I wygląda na to, że masz dużą przepustowość i być może znaczący scenariusz opóźnienia podróży w obie strony, znany również jako „długa sieć”. Tego doświadczyłem osobiście i rozwiązałem to, otwierając wiele połączeń (korzystałem z rsync). Czy możesz spróbować otworzyć wiele instancji wget (spróbuj 5, 10, 20)? Strona Wikipedii to: produkt opóźniający pasmo.

— Trevor Boyd Smith

Domyślnie raporty Wget w bajtach: [james @ lamia root] $ wget -O / dev / null 10.32.48.1/t1 / dev / null 100% [================= ====>] 100,00M 112 MB / s w 0,9 s [james @ lamia root] $ wget --report-speed = bity -O / dev / null 10.32.48.1/t1 / dev / null 100% [=== ==================>] 100,00M 932Mb / s za 0,9s

— James

Rozważ uruchomienie serwera iperf dla tcp i drugiego dla udp na komputerze hostowanym na DC. Następnie w ramach zadania cron zadzwoń do testu od swojego klienta i zobacz, jak prędkości porównują się z http get.

— Criggie,

Jaki to w ogóle plik? Czy jest kompresowalny, a serwer obsługuje kompresję HTTP? Chociaż nie możesz rozwiązać problemów z przepustowością, możesz zmniejszyć plik.

— Salman A,

16

Oprócz wymienionych innych powodów połączenia TCP nie działają dobrze z dużymi plikami, gdy produkt opóźniający przepustowość staje się duży.

Jak na skądinąd szybkim połączeniu z wyspą.

Zobacz wpis Wikipedii dotyczący strojenia TCP .

Speedtest może więc zrzucić mały plik przez połączenie z prędkością 95 Mb / s, ale wgetmoże uzyskać tylko 10 Mb / s na pliku 20 MB.

— Andrew Henle
źródło

2

To dla mnie nowa wiedza. Bardzo dobre. Rzeczywiście, produkt opóźniający pasmo jest wysoki (2,25 MB, jeśli poprawnie wyliczyłem). Szybki przegląd wykazał domyślny bufor 87 kB i maksymalnie 3,5 MB. (Zakładam, że Bajt nie bitów). Muszę zagłębić się w to, aby lepiej to ocenić. Jeśli w połączeniu speedtest pobiera wiele małych plików i rejestruje maksymalną prędkość, to wiele wyjaśnia.

— Hans Linkels,

21

Dostawcy usług internetowych często nadają priorytet ruchowi na speedtest.net, aby mogli chwalić się szybkością swoich połączeń, podczas gdy w rzeczywistości nie zapewniają tak dużej przepustowości. Doskonale zdają sobie sprawę, że większość użytkowników sprawdzi tę witrynę tylko w celu potwierdzenia.

Należy również pamiętać, że szybkość transferu zależy zarówno od klienta, jak i serwera. W dzisiejszym świecie większość serwerów dławi się w taki czy inny sposób.

Wreszcie nie ma sensu oczekiwać stabilnej przepustowości dla połączeń zagranicznych. Po prostu nie ma czegoś takiego. Musi przejść przez nieskończoną liczbę przełączników, światłowodów, centrów danych, aby dotrzeć do ostatecznej lokalizacji. Wystarczy spowolnić tylko jedną ruchomą część.

— Bviktor
źródło

Rozumiem twoje stwierdzenia, z wyjątkiem ograniczania po stronie serwera. To mój własny serwer, a gdy klient znajduje się w innym centrum danych (około 1200 km), prędkość wynosi 95 Mb / s. Nawet jeśli klient korzysta z połączenia konsumenta o przepustowości 100 Mb, ma on 65 Mb / s.

— Hans Linkels,

9

Czy możesz udokumentować swoje roszczenie? „Dostawcy usług internetowych często nadają priorytet ruchowi na speedtest.net”

— Soleil

1

@Soleil Nie za bardzo googlował

— MonkeyZeus

6

Dostawca usług internetowych, który priorytetowo traktuje ruch testowy, jest równie prawdopodobny, jak testy emisji fałszywych głównych producentów samochodów.

— Barmar

3

Anegdotycznie byłem kiedyś w stanie „naprawić” jąkający się strumień Super Bowl, wysyłając wielokrotnie ruch do speedtest.net z Raspberry Pi. Wydawało się, że priorytetem było całe moje połączenie, o ile obecny był test prędkości - różnica nocy i dnia. Nie ma wielu dowodów na to, że dostawcy usług internetowych robią podejrzane rzeczy, ale to coś.

— Cofnij

7

wgetpodać praktyczną miarę prędkości. Testy Speedtest prawdopodobnie obejmują rodzaj równoległości, która może wyjaśnić wyższe liczby.

Dla dobrego testu średniej prędkości, myślę, że czas pobierania powinien wynosić co najmniej 90-120 sekund (aby uzyskać dobrą średnią)

— Romeo Ninov
źródło

Pracuję nad instalacją wydajniejszego komputera rejestrującego i zwiększeniem rozmiaru pliku.

— Hans Linkels,

Czy potrafisz rozwinąć „rodzaj paralelizmu”? Nie widzę żadnego sposobu / powodu, ponieważ istnieje połączenie a priori 1.

— Soleil

1

@Soleil, IMHO pobierają kilka plików, nie tylko jeden. Możesz to przetestować kilkoma wgetbiegami i zsumować prędkość

— Romeo Ninov

1

Mógłbym zrównoważyć swój pomiar, ale jaka jest korzyść? Już pokazałem, że inni klienci osiągają pełną prędkość. Różnica polega na tym, że problematyczne połączenie ma opóźnienie 180 ms. Szybkie połączenia <10 ms. Czy równoległe zmniejszy efekty opóźnień? Tylko pytam.

— Hans Linkels,

1

@RomeoNinov Sprawdziłem, nie ma takiej równoległości (speedtest.net). Jeden plik na przesyłanie i jeden na pobieranie ([1-2] MB każdy).

— Soleil

3

Jednym z powodów może być to, że często maksymalna prędkość nie może być osiągnięta przez pojedyncze połączenie TCP.

Speedtest.net niedawno wprowadził tryb pojedynczego połączenia. Spróbuj tego i sprawdź, czy to robi różnicę.

Następnie do pobierania użyj na przykład aria2 z parametrami, aby użyć wielu połączeń i porównać. na przykładaria2c -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
źródło

2

Użyj Fast.com Internet Speed Test , jest to test prędkości oparty na Netflix, co oznacza, że nie można go odróżnić od usługodawców internetowych od samego Netflix.

Jest to dokładniejszy test niż jakikolwiek inny test ogólnie. Ludzie nie będą się martwić, jak szybko strona się ładuje, ale raczej o to, jak szybko buforują się filmy ze względu na zwiększoną przepustowość niezbędną do wyświetlenia filmu.

Dostawcy usług internetowych często zwiększają prędkość w oparciu o domenę, z którą ktoś się łączy, jeśli jest to test prędkości lub używa portu 8080. Podczas gdy Netflix używa portu 80, wolniejszego portu, gdy jest on traktowany priorytetowo.

— Jonathan
źródło

1

„co oznacza, że nie można go odróżnić od usługodawcy internetowego od samego Netflix” - To nieprawda, że dostawca usług internetowych zdecydowanie może zobaczyć zarówno żądanie DNS, jak i SNI na połączeniu HTTPS.

— Kevin

@Kevin fast.com kontaktuje się z serwerami Netflix, z których można pobierać, co oznacza, że emuluje filmy z samego serwisu Netflix. Chociaż przyznam wam, dostawcy usług internetowych mogą zrozumieć, że połączenie z tą konkretną witryną, która następnie kontaktuje się z serwerami opartymi na Netflix, wymaga priorytetów podobnych do speedtest.net

— Jonathan

To nie jest dokładnie nauka rakietowa. Wszystko, co muszą zrobić, to odblokować Netflix przez kilka minut lub godzin po tym, jak zobaczą połączenie fast.com. Zaletą jest oczywiście to, że możesz przejść do fast.com, aby się nie zakłócać, a następnie zamknąć kartę i oglądać Netflix na serio.

— Kevin

Osobiście podejrzewam, że jest to informatyka lub przynajmniej związana z nią, a nie nauka o rakietach. Wygląda na to, że niektórzy z większych dostawców usług internetowych (np. Bell) nie natknęli się na fast.com w ciągu ostatnich kilku lat. Tak czy inaczej uruchomienie skryptu na komputerze, który łączy się z fast.com, aby co jakiś czas zwiększać prędkość pobierania, jeśli dławienie jest wystarczająco złe, byłoby wykonalne.

— Jonathan

0

Czy to tylko ja, czy nikt nie zauważył, że powiedział Mbps i listę poleceń wget „MB / s”.

60 Mb / s, a uzyskanie 11,2 Mb jest normalne.

Mb / s i MB / s to dwie różne prędkości.

„Megabit jest o 1/8 większy niż megabajt, co oznacza, że aby pobrać 1 MB pliku w ciągu 1 sekundy, potrzebujesz połączenia o przepustowości 8 Mb / s.” Więc 11 Mb / s 8 = 88 Mb / s ... 11,2 Mb jest w rzeczywistości dobre do raportowania połączenia 60-70 Mb / s.

Czy ludzie mający pamięć tracą to. Nigdy nie uzyskasz prędkości 70 Mb / s przy prędkości testowania prędkości wynoszącej 70 Mb / s

— bla Chesley
źródło

Wydajność wgetwynosi Mb / s, co przekłada się na megabity / s . MB / s tłumaczy się na MegaBytes / s . Po prostu uruchom własne wgetpolecenie i sprawdź wynik.

— Thomas

1

@james: Domyślnie tak, ale w OP wgetpolecenie zawiera, --report-speed=bitsktóre wyniki Mb/ssą Mbit/s. Bieganie bez --report-speed=bitsdawania, MB/sco przekłada się na MByte/s. Zwróć uwagę na bi B.

— Thomas