Łatwe sprawdzanie szybkości internetu mobilnego

Zwykle do sprawdzania szybkości działania internetu korzystałem ze Speedtest.net rozwiązania popularnego i… takiego sobie. Wady są dość oczywiste – dużo reklam, na telefonie (Android) chyba nie udało mi się skorzystać, bo strona nachalnie promuje appkę.

Dziś dowiedziałem się o mającej łatwą do zapamiętania nazwę stronie Fast.com. Serwis dostarcza Netflix. Nie ma reklam, wygląd jest minimalistyczny i wszystko bez problemu działa na przeglądarce Firefox Focus pod Androidem. Przy okazji, po wybraniu show more info ładnie pokazuje nie tylko opóźnienia i prędkość uploadu, ale także ilość przesłanych danych podczas testu. Uruchomienie testu w obie strony to jakieś 50-100 MB przesłanych danych (na WiFi). Pierwsze wrażenie bardzo pozytywne.

Szybkość polskich stron internetowych cz. 2

Opisywany w poprzednim wpisie nt. badania szybkości polskich stron internetowych system trochę okrzepł, skończył się miesiąc, więc pora na konkrety. Co prawda listę badanych serwisów było widać na zrzucie ekranu, ale nie było dostępu do danych , więc teraz to naprawiam.

Zdecydowałem, że nie będę się bawił w wyciąganie średnich miesięcznych itp.  Jeśli ktoś jest zaintersowany, to w historii są linki do danych źródłowych (CSV), można sobie wyciągnąć samodzielnie. O ile ktoś będzie potrzebował, bo to, co domyślnie daje GTmetrix, z ładną wizualizacją, jest IMO w zupełności wystarczające.

Tak więc badanie wywoływane jest dla 10 wybranych serwisów (najpopularniejsze polskie oraz ecommerce, przy czym znaczenie miała domena) co 12h,  wykonywane z Londynu, przy pomocy Chrome, bez AdBlocka i na nielimitowanym paśmie.

Oto serwisy, po kliknięciu linka dostęp do wszelkich zebranych danych:

Jest jeszcze pomysł na uruchomienie testów za pośrednictwem innego serwisu, ale pozostaje to w sferze pomysłów, póki co bez planów na implementację.

UPDATE: Pomysł wyglądał fajnie, ale tylko przez miesiąc. Po pierwsze, okazało się, że dostępne są dane tylko z miesiąca, mimo obiecujących wartości „1y” i „all” w historii. Po drugie, skrypt wymaga poprawki – przez parę dni dane się nie zbierały, potem samoistnie zaczęły. Pewnie do poprawy obsługa wyjątków plus dodanie wysłania powiadomienia, choć założenie, że mógłbym coś zrobić i że by mi się chciało jest mocno optymistyczne. Po trzecie i najważniejsze, zmieniły się linki do raportów, powyższe już nie działają, co oznacza, że nawet wersja miesięczna jest średnio używalna dla kogokolwiek poza mną. Pomyślę jak to wszystko rozwiązać, pewnie skończy się na powrocie do oryginalnego pomysłu i zbierania danych samodzielnie.

Pomiar szybkości polskich stron internetowych

Podczas pewnej dyskusji nt. kondycji stron internetowych powołane zostało jako argument badanie szybkości stron internetowych robione przez firmę Hostersi. Jest to ciekawe badanie, prowadzone od lat ale… ma wady.

Pomiarów niby jest dużo, ale są one przeprowadzane przy pomocy autorskiego narzędzia uruchamianego ad hoc, przez tydzień, samo badanie publikowane raz na rok. Wszystko to powoduje, że wyniki trudno jest weryfikować samodzielnie, a jakaś zmiana na stronie obecna w danym tygodniu, czy chwilowe problemy wydajnościowe serwisu mogą zaburzać wyniki dla całego roku. Co widać nawet w raporcie po niektórych dziwnych danych.

Dla jasności – szanuję wykonaną pracę, ale gdyby to zależało ode mnie, wolałbym mieć dane zbierane z dłuższego okresu, choć z mniejszą rozdzielczością. Czyli patrzeć na trendy powiedzmy kwartalne, kosztem podatności na błąd pojedynczego pomiaru. Ale w dłuższym okresie i tak się to uśredni.

I tak narodził się pomysł, żeby zbierać i publikować w miarę na bieżąco dane dotyczące szybkości działania polskich stron internetowych samodzielnie, hobbystycznie, w sposób umożliwiający każdemu chętnemu samodzielną weryfikację wyników pomiarów.

Stawianie własnej infrastruktury oczywiście odpadło w przedbiegach. Zbyt zasobochłonne, zarówno jeśli chodzi o koszt, jak i o samą czasochłonność utrzymania. Poza tym, odpadnie możliwość peer review. Jednak serwis GTmetrix daje ciekawe możliwości badania szybkości ładowania stron i daje API, postanowiłem z niego skorzystać, co sprowadza pracę do napisania prostych skryptów w Pythonie. Dodatkowo pozwala dzielić się zebranymi danymi przy pomocy udostępniania unikatowych URLi.

Niestety, w wersji darmowej można robić tylko 20 zapytań po API dziennie, co wymusiło ograniczenie się do jednej lokalizacji (Londyn, jako najbliższy Polsce), jednej przeglądarki (Chrome bez AdBlocka), okrojenia liczby badanych serwisów do 10 (wybrane na podstawie raportu Hostersi z najpopularniejszych i ecommerce) i wykonywania dla każdego 2 testów dziennie. Wybrałem okolice godziny 8 rano oraz 20. Z doświadczenia o 8 jest już jakiś – choć niewielki – ruch w sieci, a 20 to szczyt. Wyniki planuję publikować co miesiąc, jako średnie wartości z danego miesiąca.

Badane strony w GTmetrix

Póki co, uruchomiłem skrypt, który przy pomocy crona robi „taktowanie”, czyli zleca uruchomienie testów. Dane zbierają się od paru dni. Pomyślę jeszcze, czy zamieszczać jakieś statystyki co miesiąc, czy po prostu ograniczyć się do zbierania. Raczej stanie na tym drugim… Stay tuned!

Jak usprawnić sieć w domu? cz. 5

Wpis, który chronologicznie powinien pojawić się jako drugi, ponieważ dotyczy stanu wyjściowego, czyli WiFi. Oczywiście sprzęt to opisywany niedawno TP-Link WR841 z OpenWrt. Banana Pi wpięte do portu LAN, czyli na 100 Mbps, ale głównym ogranicznikiem jest sieć bezprzewodowa. Jasności dodam, że są to wyniki sprzed optymalizacji, ale o poprawianiu WiFi napiszę innym razem. Warto też zaznaczyć, że wyniki jako jedyne są przeprowadzane na środowisku nieizolowanym, „produkcyjnym”, tj. z podłączonymi innymi urządzeniami. O ile nie powinny specjalnie rzutować na wynik, bo nie korzystały intensywnie, to na pewno wpływały w jakiś sposób ujemnie.

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.04  sec   125 MBytes  17.5 Mbits/sec  10.997 ms  1908/16040 (12%)  
[  4] Sent 16040 datagrams

2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  67.7 MBytes  9.46 Mbits/sec  186             sender
[  4]   0.00-60.00  sec  67.6 MBytes  9.45 Mbits/sec                  receiver

3.
— 192.168.0.139 ping statistics —
600 packets transmitted, 598 received, 0% packet loss, time 61057ms
rtt min/avg/max/mdev = 0.766/2.303/42.995/4.036 ms

4.
— 192.168.0.139 ping statistics —
600 packets transmitted, 596 received, 0% packet loss, time 60280ms
rtt min/avg/max/mdev = 1.918/3.953/42.202/3.747 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.04 sec  6.27 GBytes  15.0 Mbits/sec  4.305 ms  71880/822270 (8.7%)
[  4] Sent 822270 datagrams
[…]
9.
Inea Orange

Jak widać stan wyjściowy nie był imponujący. Rzekłbym nawet, że zaskakująco słabe wyniki. Widać też, że brakuje części testów – przyznaję, że nie miałem ani cierpliwości, ani warunków. Ponieważ ustawienia lekko się zmieniły w międzyczasie, zostawię z brakiem, żeby nie fałszować. Zaskakuje słaby wynik transmisji w teście syntetycznym, w szczególności w porównaniu z testem do internetu.

Jak usprawnić sieć w domu? cz. 4

Kolejnym PLC, który otrzymałem na testy, był D-Link PowerLine AV Network Starter Kit DHP-307AV. Bardziej niż konkretny sprzęt jest to przedstawiciel starszego standardu, takiego, do którego przymiarkę robiłem zawodowo, wiele lat temu, pod kątem IPTV (i nie zdecydowaliśmy się wtedy).

W stosunku do opisywanego poprzednio główna różnica widoczna na pierwszy rzut oka, to brak gniazdka sieciowego w urządzeniu. Zaprawdę powiadam wam, pomyślcie dwa razy, nim coś takiego kupicie. Jednak główna zaleta PLC to przesył danych po sieci energetycznej obok prądu, a nie zamiast. Okazało się, że większość gniazdek w domu jest pojedyncza, w szczególności te, na których przeprowadzałem testy. Chciałem mieć równe testu warunki, więc stanęło na tym, że PLC było wpięte w gniazdko, a prąd do urządzeń doprowadzałem przy użyciu przedłużaczy z innych gniazdek, zalegających malowniczo po domu.

Detali typu wygląd, czytelność sygnalizacji, umiejscowienie portów czy przycisków pomijam – nie tego dotyczy test. Zatem do rzeczy. Błędów nie będę powielał, testy tylko w optymalnym zestawieniu, dwa gniazdka w tym samym pokoju, PLC bezpośrednio w gniazdku:

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.01  sec   402 MBytes  56.2 Mbits/sec  1.923 ms  25/51490 (0.049%) 
[  4] Sent 51490 datagrams

2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec   279 MBytes  39.0 Mbits/sec    0             sender
[  4]   0.00-60.00  sec   278 MBytes  38.9 Mbits/sec                  receiver

3.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60295ms
rtt min/avg/max/mdev = 3.273/3.939/8.552/0.749 ms

4.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60235ms
rtt min/avg/max/mdev = 2.885/3.943/8.002/1.000 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.00 sec  21.0 GBytes  50.1 Mbits/sec  2.687 ms  9031/2754740 (0.33%) 
[  4] Sent 2754740 datagrams

6.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-3600.00 sec  16.0 GBytes  38.3 Mbits/sec    0             sender
[  4]   0.00-3600.00 sec  16.0 GBytes  38.3 Mbits/sec                  receiver

7.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3622284ms
rtt min/avg/max/mdev = 2.715/4.149/75.146/1.069 ms

8.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3620695ms
rtt min/avg/max/mdev = 2.862/3.903/83.121/1.154 ms

9.
brak danych

Jak widać, w porównaniu z poprzednim testem sprzętu nowszej generacji, urządzenia starszej generacji zapewniają znacząco mniejszy transfer. Choć działają stabilnie, nawet przy niższych opóźnieniach. O ile zaczną działać, bo brak danych w punkcie dziewiątym wynika z tego, że połączenia między pokojem a przedpokojem zwyczajnie nie udało mi się zestawić, mimo kilku prób.

Jeśli chodzi o pobór prądu to zarejestrowałem na pojedynczym urządzeniu od 3,2 W pod obciążeniem, przez 2,7 W przy braku przesyłu danych i podłączonych urządzeniach, do minimalnie 2,3 W parę minut po wypięciu kabla ethernet. Producent obiecuje poniżej 1 W w idle, jak widać jest więcej. Albo kwestia firmware, albo za krótko czekałem, albo urządzenia nie potrafią.