Nowy router (TP-Link Archer C50)

Poprzedni router wytrzymał cztery lata. Jakiś czas temu zaczął się wieszać – 50% strat pakietów po WiFi, pomagał restart prądowy. Nie było to może bardzo częste, ale na tyle drażniło, że dopisałem nawet codzienny reboot w cronie. Co zmniejszyło problem, ale go nie rozwiązało. I w ogóle problem jakby się nasilał. Od strony systemu (OpenWrt) nic ciekawego w logach, przełożenie w chłodniejsze miejsce, tj. zdjęcie z modemu kablowe jakby trochę pomogło, więc podejrzewam albo przegrzewanie się, albo wysychający kondensator. Tylko nie pasuje mi do tej teorii reset rozwiązujący problem na losowy okres czasu.

Teoretycznie nic, z czym nie mógłbym powalczyć, ale… trochę szkoda czasu. No i są inne powody. Po pierwsze, poprzedni router już się zwrócił. Po drugie jest to wspaniały pretekst do wymiany sprzętu na coś z 5 GHz, bo na 2,4 GHz od dawna robi się tłoczno, a coraz więcej sprzętów obsługuje 5 GHz. Wreszcie zajrzałem na stronę OpenWrt i tam wszędzie warningi, że sprzęty z 4 MB flash lub 32 MB RAM przestają być wspierane. Swoją drogą, może właśnie to była przyczyna niestabilności? Szczególnie, że trochę przeładowany softem i ogólnie na krawędzi był, zdecydowanie wbrew zaleceniom, jak je teraz czytam.

Tak czy inaczej, kupiłem sprzęt. Wybór był nieco skomplikowany, choć wymagania miałem proste: 8 MB flash, 64 MB RAM, wsparcie dla 5 GHz i 802.11ac i oczywiście wsparcie przez OpenWrt. Szybko ustaliłem, że jednym z tańszych urządzeń dostępnych w Polsce spełniających kryteria jest TP-Link Archer C50. Jednak żeby nie było zbyt prosto, okazało się, że wsparcie jest zależne od wersji hardware. Ogólnie nie rozumiem tej mody wśród producentów, żeby robić wiele różnych urządzeń z tą samą nazwą. Wersja hardware spokojnie mogła by być ujęta w nazwie, przynajmniej klient od razu wiedziałby, co kupuje.

Wyszło mi, że potrzebuję albo v3, albo v4. Przy czym sprzęt jest w zasadzie ten sam, a główny problem jest z formatem obrazu – prawdopodobnie v4 nie dorobi się „klikalnej” wersji obrazu na stronie i trzeba będzie się bawić w samodzielne składanie obrazu. Nie jest to jednak coś, co spędza mi sen z powiek.

Na Allegro nie jest łatwo ustalić wersję hardware. Mało który sprzedawca chwali się wprost. Zadałem pytanie o wersję chyba czterem albo pięciu, odpisał jeden. I kupiłbym tam, gdyby nie fakt, że zdążył zakończyć sprzedaż. Chociaż w sklepie na stronie nadal były dostępne. Ostatecznie kupiłem u innego sprzedawcy kota w worku. Kot okazał się być v4.

Tradycyjnie nie przechodziłem na OpenWrt od razu, tylko dałem szansę firmware’owi producenta. Okazało się, że wgrany jest najnowszy dostępny. Tradycyjnie dostępnych wiele opcji konfiguracyjnych. Można nawet wybrać z GUI cykliczny reboot, czego nie było w poprzednich wersjach. Można zdefiniować tryb nocny, kiedy diody mają być wyłączone i ustalić – niezależnie – moc każdej z kart sieciowych (low-medium-high). Wygląda to naprawdę przyzwoicie. Dwa zakresy oznaczają de facto dwa niezależne interfejsy sieciowe i prawdopodobnie dwie oddzielne karty z dwiema antenami każda. Obie sieci ustawiłem na średnią moc.

Ogólnie po trzech tygodniach korzystania jestem zadowolony. Na razie zostaje firmware producenta. Jak na sprzęt za 110 zł działa bardzo fajnie i stabilnie. Tam gdzie to możliwe korzystam z 5 GHz. Pokazuje niby słabszy sygnał, niż na 2,4 GHz ale działa bardzo dobrze i speedtest na luzie, powtarzalnie, pokazuje zarówno maksymalny upload, jak i download w stosunku do tego co oferuje ISP.

Testy szybkości sieci wewnętrznej i pomiary poboru prądu – jak mi się przypomni.

Ł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.