Menu

Pomiędzy bitami

Techno, porno i duszno. Blog niezupełnie technologiczny.

Jak usprawnić sieć w domu? cz. 1

rozieblox

Wstęp

Wpis jest wstępem do serii mini testów, które przeprowadziłem lub przeprowadzę w najbliższym czasie. Chodzi o rozwiązanie kwestii dostępu urządzeń w domu do internetu i zapewnienia ich łączności pomiędzy sobą. Powodem było moje WiFi, które choć doprowadzone aktualnie do zadowalającej używalności, niekoniecznie było optymalne zarówno jeśli chodzi o stabilność połączenia, jak i oferowane przepływności czy opóźnienia. Na rynku istnieje kilka rozwiązań, które mają za zadanie pomóc w dostarczeniu sieci, niedawny wpis o PLC przypomniał mi, że kiedyś interesowałem się bardziej tematem, a technika poszła naprzód.

Szybkie pytanie na wewnętrznym forum firmowym czy komuś nie zalega parka PLC spotkała się z pozytywnym odzewem (uroki pracy w większej firmie, z otwartymi geekami - ciekaw jestem czego nie dałoby się znaleźć... ;-)) i okazało się, że nie tylko zalega chwilowo, ale są różnego typu, stąd pomysł na porównanie i podzielenie się wnioskami.

Nie ma to być test uniwersalny ani profesjonalny - robię go przede wszystkim dla siebie i w dostępnym mi środowisku (a np. typ ścian czy otoczenie może mieć kolosalne znaczenie dla WiFi, podobnie wygląda kwestia sieci elektrycznej dla PLC), mam jednak nadzieję, że uda się wyciągnąć jakieś wnioski ogólne i może komuś pomoże w wyborze rozwiązania.

O ile nie napisano inaczej, wykorzystywany jest firmware dostarczony z urządzeniami. Systemy nie są specjalnie tuningowane - ot, linuksowy default. Z oczywistych względów trudno mi wypowiadać się na temat stabilności poszczególnych rozwiązań w dłuższym okresie czasu.

Topologia sieci

Topologia sieci jest następująca: modem ISP (kablówka) w przedpokoju, podłączony ethernetem do routera. Router (obecnie TL-841) z wgranym OpenWRT/LEDE dostarcza internet reszcie urządzeń po WiFi. Przedpokój to w miarę centralny punkt w mieszkaniu, odległość od urządzeń końcowych (laptopy, smartfony) ok. 7 metrów, część urządzeń pracuje w 802.11n, część w 802.11g i tak zostanie - modernizacja czy wymiana końcówek są nieopłacalne.

Dla jasności: to działa od lat i w zasadzie wystarcza, jeśli chodzi o przepływność. Wystarczało i na 802.11g, gdy transfery (do mojego laptopa) wynosiły 15-18 Mbps (wg speedtest.net). Po zmianie routera na nowszy jest lepiej - 30 Mbps. Nadal jest to gorzej niż to, co oferuje operator (60 Mbps), ale w zupełności wystarcza do transferów "z zewnątrz". Zobaczymy jednak, czy są jakieś alternatywy i czego się spodziewać.

Ani mieszkanie w kamienicy, ani dość zaszumiony eter na 2,4 GHz, nie pomagają w dobrym działaniu WiFi, więc nieco gorzej wygląda sytuacja, jeśli chodzi o stabilność. Rzadko, bo rzadko, ale zdarzały się problemy (straty do routera, wzrost czasów odpowiedzi). Zwykle, w czasach gdy korzystałem z oryginalnego firmware producenta, wystarczał restart routera lub sprawdzenie jak wygląda sytuacja w eterze przy pomocy WiFi Analyzera i zmiana kanału na wskazany jako najlepszy (czyli najmniej używany).

Swoją drogą zmiana kanału na nieużywany jest najprostszym sposobem na poprawę zasięgu czy jakości WiFi, więc jeśli ktoś szuka odpowiedzi na pytanie jak poprawić sygnał WiFi, to zdecydowanie polecam zacząć od tego.

Pomiary

Wykonywane są cztery testy wewnętrzne, oraz ogólny test przy pomocy speedtest.net (beta, czyli bez Flash). Testy wewnętrzne wykonywane były w dwóch wariantach: krótkim (w założeniu ok. 60s) i długim (ok. 3600s).

  1. iperf3 -u -b 0 -t 60 -c 192.168.10.126
  2. iperf3 -t 60 -c 192.168.10.126
  3. ping -i 0.1 -c 600 192.168.10.126
  4. ping -s 1500 -i 0.1 -c 600 192.168.10.126
  5. iperf3 -u -b 0 -t 3600 -c 192.168.10.126
  6. iperf3 -t 3600 -c 192.168.10.126
  7. ping -i 0.1 -c 36000 192.168.10.126
  8. ping -s 1500 -i 0.1 -c 36000 192.168.10.126
  9. speedtest.net

Jak widać jest to pomiar przepływności przy użyciu pakietów UDP, TCP oraz pomiar opóźnień przy pomocy ping ze standardową oraz maksymalną (MTU 1500) wielkością pakietu. Ostatni test to "realne" połączenie z internetem. Wykorzystywane serwery mojego ISP oraz Orange, który często był wskazywany jako najlepszy.

Za klienta służy mój laptop z Debianem, za sondę posłużyło Banana Pi (jedyny SoC z gigabitowym portem, który miałem pod ręką). W obu systemach wykorzystany iperf3. Pomiar nie był jedyną czynnością wykonywaną przez laptopa, ale - poza testami WiFi - był wykorzystany osobny interfejs, a obciążenie było typowe, bez ekstremów.

Dodatkowo mogą pojawić się uwagi, jeśli coś nieplanowanego podczas testów rzuci mi się w oczy.

Wyniki bazowe

Na wstępie spiąłem oba urządzenie kablem "na krótko" i uruchomiłem testy. Synchronizacja oczywiście 1 Gbps.

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.00  sec  6.07 GBytes   869 Mbits/sec  0.136 ms  592341/795464 (74%)
2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  5.47 GBytes   784 Mbits/sec  138             sender
[  4]   0.00-60.00  sec  5.47 GBytes   783 Mbits/sec                  receiver
3.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 62319ms
rtt min/avg/max/mdev = 0.291/0.372/0.549/0.031 ms
4.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 62290ms
rtt min/avg/max/mdev = 0.427/0.549/24.612/0.996 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.00 sec   374 GBytes   893 Mbits/sec  0.220 ms  36944269/49033499 (75%)
6.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-3600.00 sec   349 GBytes   833 Mbits/sec  8735             sender
[  4]   0.00-3600.00 sec   349 GBytes   833 Mbits/sec                  receiver
7.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3745436ms
rtt min/avg/max/mdev = 0.278/0.369/40.914/0.398 ms

8.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3745111ms
rtt min/avg/max/mdev = 0.260/0.500/2.861/0.046 ms

9.
nie dotyczy

Jak widać bez większych niespodzianek - osiągnięte wyniki wynikają raczej z ograniczenia samego Banana Pi. Mimo to widać, że jest szybko, czasy odpowiedzi niskie i jest stabilnie.

© Pomiędzy bitami
Blox.pl najciekawsze blogi w sieci