Menu

Pomiędzy bitami

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

Raspbian i uruchomienie modemu GSM Huawei E3131

rozieblox

Uruchomienie modemu Huawei E3131 (hilink) pod Debianem opisałem wcześniej, ostatnio pisałem o perypetiach związanych z tym, że na Debianie działa, na Raspbianie nie działa. Dziś zagadka została rozwiązana.

Udałem się na kanał IRC Raspbiana, w nadziei, że dostanę wskazówki w czasie kiedy będę przeprowadzać debug. Czasami nie ma się co męczyć, bo po prostu można o czymś nie wiedzieć, jak miało to miejsce w przypadku uruchomienia SSH na Raspbianie. Poza tym, takie pytanie o pomoc i dostarczenie pełnych danych o problemie działa trochę jak gumowa kaczuszka.

Nim dobrze skończyłem pisać, dostałem namiar na ten wpis. Wygląda paskudnie? Ano wygląda. Ale działa - po wydaniu podanego polecenia pojawił się interfejs eth1 w systemie. Ale być może wystarczy doinstalować sg3-utils? Niestety nie - opisany sposób działa tylko do rebootu Raspberry Pi czy też do wyjęcia i włożenia modemu (nie pamiętam, oba mało akceptowalne...). Od biedy mógłbym z tym żyć, bo prosty skrypt do crona załatwi sprawę, ale... na Debianie jest bardziej elegancko, więc drążyłem temat.

Skoro przyszło do pakietów, to zauważyłem, że na desktopie mam zainstalowany pakiet:

ii  modemmanager                              1.6.4-1                                                 amd64        D-Bus service for managing modems

Brzmi obiecująco, tym bardziej, że dotyka D-Bus. Na Raspbianie tego pakietu nie było... Doinstalowałem pakiet, reboot Raspberry Pi i... Działa. Nie jest identycznie jak w Debianie, bo nadal interfejs to eth1 i IP pobiera automatycznie z DHCP, ale to detale - najważniejsze jest działające wyjście na świat.

Podsumowując: aby działały modemy typu dongle USB w Raspbian, należy doinstalować pakiet modemmanager.

Wpis pojawia się w kategorii DSP2017 z racji tego, że płytka z ARM będzie robiła za stację testową. Jeśli wszystko pójdzie dobrze, jeszcze dziś...

Terroryści wszystkich krajów, łączcie się!

rozieblox

Parę dni temu mignęła mi wiadomość na stronach Debiana, że jeden z developerów, Dmitry Bogatov, został zatrzymany. Przez moment zastanawiałem się, cóż takiego mógł zrobić i czy przypadkiem nie chodzi o zbieg okoliczności i działalność poza projektem Debian i pozainformatyczną w ogóle, bo trochę mi się w głowie nie mieściło jak projekt Debian może powodować aresztowanie. Nawet w Rosji.

Sprawa się wyjaśniła, chodzi o terroryzm[1]. Dokładniej, o prowadzenie węzła Tor. W dodatku wyjściowego, czyli tzw. exit node. Projekt Tor uruchomił akcję, w której wzywają do uruchomienia węzła wyjściowego lub jakiegokolwiek węzła Tor w geście solidarności z aresztowanym. Uruchomione w ramach akcji węzły powinny mieć w nazwie Bogatov lub KAction.

O ryzyku prowadzenia węzła Tor pisałem jakiś czas temu, miałem też notkę o konfiguracji relay node, czyli wersji bezpiecznej, w wersji z eleganckim monitoringiem w konsoli.

[1] Gdyby ktoś miał wątpliwości: w dzisiejszych czasach każda nieprawomyślność względem rządzących może być podciągnięta pod terroryzm, niezależnie od miejsca na świecie.

Prawie jak stacja testowa

rozieblox

Były święta i wolne. W planach miałem uruchomienie stacji testowej w domu, na Raspberry Pi, ale po namyśle stwierdziłem, że jednak wolę zamienić Banana Pi, robiące aktualnie za router u rodziców z moim Raspberry Pi i testować na BPi. Przy okazji miałem nadzieję wyjaśnić zagadkę niedziałającego z BPi zasilacza domowej produkcji, który świetnie działa z RPi. Podejrzewam kabel USB, ale o tym innym razem.

W każdym razie spakowałem RPi z zainstalowanym podstawowym systemem i dostępem po SSH, wziąłem też sporo kabli USB, zasilacze, mirniki napięcia. Ot, wszystkie okoliczne graty. Wziąłem też testowy modem Huawei E3131, na wypadek gdyby przyszło mi do głowy zastąpienie istniejącego, również Huawei E3131 tyle, że starszej generacji, bez hilink.

Na miejscu dokonałem szybkiego kopiowania skryptów i... przyszedł mi do głowy szatański plan. Przecież mogę uruchomić oba modemy w RPi i testować w warunkach produkcyjnych. Tyle, że zdalnie. Niestety, szybko okazało się, że mimo starannego choć szybkiego skopiowania skryptów RPI nie nawiązuje łączności ze światem. Wielkiej filozofii w skryptach nie ma, prawa identyczne. Stary Huawei nie chce działać. Wetknąłem więc nowy modem, z hilink i stwierdziłem, że w sumie najwyżej zostanie RPi z nowym modemem robiące za router, a BPi przetestuję po powrocie do domu i od razu zrobię z niego stację roboczą. Tyle, że okazało się, że modem z hilink niby nawiązuje połączenie (jest ustawiony, by robił to automagicznie), przynajmniej wskazuje na to kolor diody ale... w systemie nie powstaje interfejs. Czyli żaden z dwóch modemów na USB nie zadziałał na RPi!

Lekko tylko klnąc pod nosem szybko wróciłem do działającej konfiguracji z Banana Pi robiącym za router GSM, czyli zupełnie do punktu wyjścia, bez jakichkolwiek postępów - ani nie mam uruchomionej stacji testowej, ani nie zluzowałem BPi w celu przetestowania zasilacza.

Jednak są pewne... zmiany, bo ciężko to nazwać postępem:

  • Mam zagadkę pt. "na Raspbianie nie działają modemy USB". Jak patrzę we wcześniejszy wpis o SSH, to jakiś Raspbian Lite. Może to jest przyczyną? Może customowy kernel Raspbiana? Przetestuję w chwili wolnej.
  • Jakimś cudem zadziałało zapięcie Banana Pi zarówno jako źródła danych, jak i "klienta" w hubie USB. Jak ostatnio sprawdzałem, to w tej konfiguracji się nie uruchamiał, a RPi działało bez problemu. Zastanawiam się, czy znowu nie chodzi o kabel.
  • Kolejnym zaskoczeniem jest to, że Raspberry Pi nie musi być wpięte w ww. sposób do huba USB, by działało. Okazało się, że wystarczy je zapiąć jako źródło danych i... dostaje zasilanie. Jest to dla mnie totalną zagadką, bo do tej pory nie przyszło mi do głowy, ale działa. W sumie fajne, bo mam jeden port w hubie USB więcej wolny.


Czyli w DSP2017 zastój, ale czegoś nowego się dowiedziałem i jest co robić. Następny wpis raczej również będzie metatematyczny, prawdopodobnie znowu o ciekawych projektach w DSP2017. Z rzeczy związanych bardziej bezpośrednio - prawdopodobnie w przyszłym tygodniu jakąś stację testową jednak uruchomię. Mam nadzieję, że będzie to RPi z rozwiązaną zagadką modemów USB...

Status abcc - 75% zrobione

rozieblox

Za wiele się nie wydarzyło w tym tygodniu w projekcie. Nie uruchomiłem i raczej nie uruchomię stacji testowej, bo jakoś nie ma weny. Za to zrobiłem względny porządek z opisami i funkcjonalnościami, więc powinno dać się względnie komfortowo uruchomić. Gdyby ktoś miał Linuksa i chciał się pobawić - zapraszam i czekam na uwagi. Póki co wyniki są wyświetlane na stdout i całość nie działa w pętli, tylko wykonuje jeden przebieg, ale to detale.

Rozważam uruchomienie stacji testowej oraz przejście na wypisywanie rzeczy do dorobienia/poprawki jako issues.

Czas na DSP2017 został zjedzony przez inną nową zabawkę - Pyevolve. Jest to biblioteka do algorytmów genetycznych, które chcę wykorzystać do rozwiązywania pewnego zagadnienia. No i wsiąkłem w testy, zabawę, przeglądanie dokumentacji i kodu. Z zalet: chyba pierwsza biblioteka, która wygląda na używalną. Jeśli ktoś zna inne godne uwagi (proste, rozszerzalne), to poproszę namiar.

A skoro o algorytmach genetycznych mowa - jest konkurs dotyczący algorytmów genetycznych. Chociaż ja się na grant raczej nie łapię...

Dlaczego wyłączyłem reklamy AdSense?

rozieblox

Z niewiadomych dla mnie powodów sporą popularność zyskał ten artykuł nt. wyłączenia reklam AdSense. Sprawdziłem fakty i niemal dwa lata temu pisałem o odchudzaniu bloga, w tym o wyłączeniu reklam Google. Przeczytałem jeszcze raz, skonfrontowałem z ww. artykułem i stwierdziłem, że warto dodać parę słów.

We wpisie poruszyłem tylko jeden aspekt - niskie zarobki (tak niskie, że trudno tu mówić o zarobkach - tu polecam artykuł, bo ja zupełnie niekomercyjnie i amatorsko podchodziłem do tematu), ale powodów było tak naprawdę więcej i uważam Google AdSense za bardzo słaby produkt. Po pierwsze, notoryczne problemy z pojawianiem się reklam w językach innych, niż polski i ew. angielski. Jeśli nawet nie robią detekcji języka, to deklaracja języka jest jasna czy to w samym HTML, czy w Google webmaster tools. O ile "międzynarodowy" angielski jeszcze bym od czasu do czasu zrozumiał, to notorycznie pojawiały się języki takie jak niemiecki, turecki czy jakieś skandynawskie. Nie pomagało ani blokowanie reklam, ani dostawców. Czyli z mojego widzenia wyświetlane były śmieci.

Druga sprawa, to niedostosowane tematycznie reklamy połączone z brakiem jakiegokolwiek uczenia się, których kategorii nie chcę widzieć na blogu. Oczywiście można wybrać kategorie wrażliwe, ale nawet przy wyłączeniu wszystkich notorycznie pojawiały się na blogu preparaty na łysienie itp. paramedyczne atrakcje. Jawnie zablokować tego nie sposób, przy blokowaniu pojedynczych żadna korelacja nie jest stosowana. Czyli znowu śmieci.

Kolejna sprawa to reklamy wprowadzające w błąd. Przede wszystkim chodzi o reklamy krzyczące na urządzeniach mobilnych o tym, że na urządzeniu są wirusy. Raczej nie widziałem tego u siebie, ale widać to zwykle na urządzeniach mobilnych, a tak raczej nie zdarzało mi się oglądać bloga, natomiast temat znam zarówno z innych stron, jak i aplikacji ze sklepu Play. Zupełnie nie wiem, czemu nie jest to blokowane na wejściu globalnie. Żeby było weselej, chyba korzystał z tego któryś bardziej znany producent antywirusa. Albo po prostu domena była podobna... Problem jest taki, że ktoś to w końcu kliknie (mi się zdarzyło) i zainstaluje jakiś syf na telefonie. Czy to świadomie, czy nieświadomie...

Z punktu widzenia Google, na krótką metę, nie ma znaczenia, czy reklamy wyświetlają z sensem, czy bez sensu. Bardziej opłaca im się wyświetlić reklamę zupełnie niedopasowaną, niż nic nie wyświetlić. Jeśli nikt nie kliknie, to nie płacą, jeśli ktoś kliknie, nawet przez pomyłkę to zarabiają. A że Internet wygląda coraz bardziej jak zawalone bez ładu i składu reklamami polskie miasta? Nie ich problem...

Allegro Tech Talks Poznań #4 - wrażenia

rozieblox

W projekcie abcc panuje chwilowy zastój, spowodowany czynnikami różnymi - od osobistych (bardziej, znacznie bardziej), przez zawodowe (mniej, znacznie mniej), ale faktem jest, że spocząłem na laurach nieco i nic się od ostatniego wpisu nie zmieniło w temacie. Plan jest taki, żeby uruchomić sobie stację testową opartą o Raspbbery Pi, która będzie działać na dwóch lub trzech łączach (kabel, modem GSM i być może, jeśli RPi wyrobi prądowo, karta WiFi) i zrzucać pomiary, w celu lepszego dobrania parametrów. Ale to plany...

Tymczasem w ramach pożeraczy czasu byłem w zeszłym tygodniu na spotkaniu Allegro Tech Talks Poznań #4. Staram się bywać, jeśli akurat mam czas. Jeśli dobrze zrozumiałem, po raz pierwszy można było wysłuchać przez net na żywo, ale jakoś nie przepadam za taką formą - lepiej mi się obiera na żywo, nie mam nawyku słuchania przez net. No i zawsze można spotkać znajomych i poplotkować.

Prezentacje były dwie, obie dotyczyły Apache Solr, więc zupełnie nie moja działka, i przyznaję, że wahłem się, czy w ogóle iść, ale obie były IMO bardzo dobrze i interesująco poprowadzone, więc części merytorycznej też nie żałuję.

Pierwsza prezentacja dotyczyła uruchamiania Solra w kontenerach dockerowych, poczynając od tego jak to skonfigurować i uruchomić, przez przedstawienie wyników benchmarków pomiędzy sprzętem fizycznym (bare metal), przez pełną wirtualizację, po kontenery. Różnice były duże, przedstawione dane przekonują do kontenerów, ale... Zawsze jest jakieś ale, w tym przypadku testy były robione na ustawieniach domyślnych. Z jednej strony rozumiem, bo jakiś wspólny mianownik trzeba mieć, z drugiej produkcję konfiguruje się pod konkretny przypadek. Niemniej, różnice były na tyle istotne, że konfiguracja raczej nie będzie w stanie ich zniwelować. W sumie można było traktować tę prezentację mniej jako o Solr, bardziej jako o dockerze.

Druga prezentacja dotyczyła optymalizacji Solra w Allegro. Jak pisałem, nie moja działka, więc momentami była to trochę chińszczyzna (na zasadzie: nie wiem co to dokładnie jest), ale opowiedziane przystępnie, ciekawie i z przykładami. Mocno nieoczywiste przypadki i wyniki, efekty dobre. Stawiam, że dla osób zajmujących się Solrem perełka. Jest dostępna w wersji online.

Spotkałem też starych znajomych i poplotkowaliśmy, więc ogólnie bardzo udane wydarzenie - 10/10.

Pierwsze pomiary

rozieblox

Wygląda, że w końcu mogę napisać, że powstało coś działającego. Nie jest to oczywiście pełna funkcjonalność, ale same pomiary są skończone. Nie twierdzę, że to ostateczna wersja, w szczególności muszę się przyjrzeć logowaniu, ale to jest ten moment, kiedy mogę pobawić się wartościami z konfiguracji i zobaczyć, jak wpływają na działanie w realnych warunkach.

Jak to wygląda? Otóż tak na szybko, uruchamiając modem GSM w sieci Virgin Mobile (3G) zarejestrowany do T-Mobile (roaming):

INFO:__main__:Route default got score 24.1516556059 on interface wlan0
INFO:__main__:Route default got score 89.6018913814 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 23.7111227853 on interface wlan0
INFO:__main__:Route default got score 64.5852940423 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 24.101962362 on interface wlan0
INFO:__main__:Route default got score 63.8392652784 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 23.9711829594 on interface wlan0
INFO:__main__:Route default got score 78.0421457793 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 66.7648989057 on interface wlan0
INFO:__main__:Route default got score 62.6970052719 on interface enx582c80xxxxxx

Widać, że w ostatnim pomiarze domowe WiFi (lub operator, ale stawiam na WiFi) dało się we znaki i wypadło gorzej, niż modem GSM. Różnica jest jednak minimalna i do zmiany routingu by nie doszło, nawet na domyślnych wartościach.

Wyniki po zalogowaniu natywnie, czyli do Play:

INFO:__main__:Route default got score 23.7996305738 on interface wlan0
INFO:__main__:Route default got score 307.032244546 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 24.561555045 on interface wlan0
INFO:__main__:Route default got score 267.205837795 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 24.0223884583 on interface wlan0
INFO:__main__:Route default got score 268.849682808 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 23.7405095782 on interface wlan0
INFO:__main__:Route default got score 275.927570888 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 38.6582265223 on interface wlan0
INFO:__main__:Route default got score 287.999381338 on interface enx582c80xxxxxx

Wszystkie wyniki dla przykładowego pliku konfiguracyjnego z repo, z dostosowaną nazwą interfejsu (jest interfejs modemu zamiast eth0) i zmienionym poziomem logowania na INFO. Wywołanie w pętli 5 razy:

for i in {1..5}; do python abcc.py --config local_test.yaml; done

Przyznaję, że jestem zaskoczony wynikami - wydawać by się mogło, że natywnie będzie działać lepiej, a tu niespodzianka. Muszę jeszcze dokładniej potestować na różnych urządzeniach, dotychczas miałem wrażenie, że w roamingu jest gorzej. Ale to już temat na inny, niezwiązany z DSP2017, wpis.

Przy okazji, to drugie wywołanie wykonuje się 71 sekund, czyli około 14 sekund na jeden pełen przebieg, a ilość przesłanych podczas badania danych (odczyt z ifconfig) to:

RX packets 11342  bytes 7440400 (7.0 MiB)
TX packets 9789  bytes 1133957 (1.0 MiB)
RX packets 11640  bytes 7475184 (7.1 MiB)
TX packets 10087  bytes 1169257 (1.1 MiB)

Czyli jakieś 7kB RX i 7 kB TX per pomiar. Czyli jakieś 10 MB/dobę, przy założeniu, że będzie wywoływane co minutę, 27/7. Czyli mniej więcej mieści się w limicie bezpłatnego pakietu Freemium w Virgin Mobile. :-)

Skrypty pomocnicze

rozieblox

Wspominałem, że pewna część działania skryptu odbędzie się w zewnętrznych skryptach. Powiedzmy, że pluginach, choć to myląca nazwa. I że będą w Bashu.

Zrobiłem listę skryptów pomocniczych, których planuję używać:

  • ustawianie routingu do danego IP przez dany interfejs (bardziej gateway)
  • usunięcie routingu do danego IP przez dany interfejs (gateway)
  • ustawienie (domyślnego) routingu przez dany interfejs i gateway
  • zdjęcie (domyślnego) routingu przez dany interfejs i gateway

Jeśli chodzi o postępy, to pojawiło się wsparcie dla interfejsów, zarówno po stronie skryptu, jak i konfiguracji. Tak naprawdę pojawiła się cała sekcja interfaces, dla każdego interfejsu są określone nazwy tras, których parametry są zdefiniowane w sekcji routes. Taka konstrukcja, bo przecież nie każdy interfejs musi umożliwiać routing do każdej sieci, a nie chcę wymuszać cokolwiek długiej definicji trasy dla każdego interfejsu. Poza tym, łatwo byłoby w takim przypadku o błąd typu inne wagi czy IP.

Żeby można było mierzyć jakoś łącza do danej sieci (route) przez dany interfejs brakuje tak naprawdę pierwszych dwóch skryptów i ich wywołania - stosowne funkcje istnieją, ale są puste. Pewnie jutro/pojutrze. Mam nadzieję, że od razu pokażę pierwsze realne efekty działania, czyli wyniki pierwszych pomiarów. Stay tuned!

DSP2017 - co ciekawsze projekty

rozieblox

Ostatni dzwonek na wpis, a w związku z aurą i nawałem innych zajęć niewiele się u mnie wydarzyło[1], więc pozwolę sobie zacząć małą metatematykę, czyli pisać o projektach, które przykuły moją uwagę i które planuję śledzić. Ocena zupełnie subiektywna. Raczej ograniczam się do "żywych", czyli mających szanse w konkursie, projektów. Trochę nawiązując do Blog Day, ograniczę się jednorazowo do pięciu sztuk. Docelowo pewnie zmienię linki na bezpośrednie do blogów lub repo na GitHubie.

http://uczestnicy.dajsiepoznac.pl/profil/adrian-dzik - Instant Dinner czyli podpowiadanie co tu ugotować z dostępnych w lodówce składników. Pomysł mi się bardzo podoba i może się przyjąć, choć korzystać raczej nie będę - nie mam cierpliwości do wklepywania wszystkiego i nie lubię gotować z przepisów. Parę ciekawych wyzwań - interfejs, baza przepisów.

http://uczestnicy.dajsiepoznac.pl/profil/pawel-filipek http://uczestnicy.dajsiepoznac.pl/profil/pawel-panek - dwa projekty związane z modnym temat badania czystości powietrza. Tu: informowania o zanieczyszczeniu w danym miejscu. Po cichu liczę, że będzie kolaboracja z projektem Smolgy o którym niedawno pisałem.

http://uczestnicy.dajsiepoznac.pl/profil/kamil-kubacki - projekt Citizen, czyli zgłaszanie do władz miasta/służb uszkodzeń itp. Po prostu zgłaszasz dziurę w jezdni (geolokalizacja, fota, opis) i jest to odpowiednio przeroutowane dalej, nie trzeba się edukować/odbijać od kolejnych instytucji. Przyznaję, że myślałem o czymś podobnym niedawno. Widzę fajne możliwości - ranking najsprawniej działających miast/organizacji w danym mieście (np. czas od zgłoszenia do usterki). Widzę też jeden problem: żeby to działało, instytucje muszą się zaangażować...
Podobna tematyka http://uczestnicy.dajsiepoznac.pl/profil/andrzej-chmielewski - niestety wygląda na martwe.

http://uczestnicy.dajsiepoznac.pl/profil/maciej-sykala - działko na gołębie oparte o Raspberry Pi. Temat niezbyt mi się podoba, ale przyznaję, że zakres robi wrażenie i... ciekaw jestem efektu. BTW dawno temu czytałem, że w Korei Południowej studenci projektowali automatyczne wieżyczki strzelnicze do pilnowania granic. Nie pamiętam, czy była analiza obrazu, czy po prostu wykrywanie ruchu...

http://uczestnicy.dajsiepoznac.pl/profil/sebastian-czarnecki - arduino sterowane po wifi. To mi się najprawdopodobniej zwyczajnie przyda w niedalekiej przyszłości.

Na wypadek gdyby powyższe nie wyczerpywało wymagań wpisu o IT, to przyszła mi do głowy nieco inna formuła konkursu programistycznego, która mogłaby trochę pomóc w rozwoju projektów. Pierwszy etap to prezentacja pomysłów, pisanie kodu i blogowanie (czyli dokładnie jak DSP), drugi etap to połączenie się ludzi w zespoły i wspólne rozwijanie projektów. Można by to zakończyć jakimś hackatonem, żeby ludzie się poznali na żywo. A może istnieje już coś takiego?

Co prawda nie widzę za bardzo kryteriów oceny w powyższym układzie, ale mogłoby to dać coś trwalszego i większego, niż małe projekciki, nauczyć pracy w zespołach, umożliwić poznanie ludzi i wymianę wiedzy np. o narzędziach. No ale ja cały ten konkurs traktuję bardziej jako pretekst, czyli droga jest ważniejsza od celu. ;-)

[1] Przynajmniej niewiele zostało commitnięte, za to wkrótce pierwsze pomiary na dwóch łączach i pewne uwagi nt. internetu w Virgin Mobile.

Logowanie

rozieblox

Pora dorobić logowanie w skrypcie. Nie będę tu przepisywał tutoriali, więc jedynie odeślę do opisu logowania w Hitchhiker's guide to Python oraz chyba nawet lepszego wpisu na temat dobrych praktyk logowania w Pythonie Docelowo konfiguracja logowania w pliku konfiguracyjnym. Waham się czy jednak syslog, czy może osobny plik, ale to jest detal.

Wczoraj w pociągu rozpisałem wstępnie, co chciałbym logować na poszczególnych poziomach i wyszło mi coś takiego:

WARNING/ERROR:

  • błąd otwarcia lub parsowania pliku konfiguracyjnego
  • nieistnienie interfejsu zdefiniowanego w pliku konfiguracyjnym
  • błąd zwrócony przez skrypty pomocnicze
  • brak skryptu pomocniczego, jeśli był zdefiniowany w pliku konfiguracyjnym[1]
  • nieosiągalne IP[2]

INFO:

  • znalezienie lepszej trasy i zmiana routingu, czyli podstawa
  • ostateczna punktacja dla danego interfejsu (docelowo może w DEBUG?)
  • znalezienie lepszej trasy, niż istniejąca, z pominięciem kosztu przełączenia[3]

DEBUG:

  • chwilowe zmiany routingu per badane IP
  • dane wczytane z konfiguracji
  • parametry wywołania funkcji
  • punktacja dla interfejsu z rozbiciem na składowe
  • parametry wywołania skryptów pomocniczych

Domyślny loglevel to oczywiście INFO. Jeśli wszystko pójdzie OK,to zmiany pojawią się w repo dziś wieczorem - niestety czas goni, a dwa wpisy w tygodniu muszą być...

[1] Wybiegam w sekcję ogólną konfiguracji, która dopiero powstanie, o skryptach pomocniczych planuję napisać w kolejnym wpisie.
[2] Jeśli będzie często występowało, to warto je usunąć, żeby nie zaburzało wyników.
[3] W celu poinformowania użytkownika, że być może warto zmienić przy okazji konfigurację sieci.



Początek

rozieblox

No to wysłałem na GitHuba to co mam w tej chwili. Nie ma tego wiele - w zasadzie jeśli chodzi o kod to jest to dokładnie wersja testowa o której pisałem wcześniej. Zupełnie nie miałem czasu i weny na siedzenie z kodem.

Ale nie jest tak, że nic nie przybyło w kwestii projektu. Po pierwsze, dotarł modem i udało mi się go uruchomić, więc będzie na czym testować. Po drugie, zrobiłem lekkie porządki w plikach i zaktualizowałem opis. Po trzecie i najważniejsze: chyba rozwiązałem problem wag. Proste rozwiązania są najlepsze, na papierze i szybkim teście wygląda wstępnie OK. Oczywiście jest to średnia ważona - musiałem mieć jakieś zaćmienie, że od razu o niej nie pomyślałem, ale powiedzmy, że bardziej myślałem o pliku konfiguracyjnym.

Co poza tym w temacie DSP2017? U mnie nic, poczytałem za to trochę wpisów. innych uczestników Co prawda w repozytoria nie zaglądałem, ale z wpisów mogę wywnioskować, że wszyscy mają mało czasu, generują niewiele kodu za to piszą, bo... muszą. Czyli za dużo blogowania, za mało programowania, ale chyba autor konkursu świadomie tak wybrał. Wnioskuję po dopuszczeniu wpisu niezwiązanego tematycznie z projektem jako drugiego. IMVHO trochę szkoda, bo czas zabiera, a wnosi niewiele.

Huawei E353/E3131 w Debianie

rozieblox

Kiedyś opisywałem uruchomienie Aero2 z modemem Huawei E3131. Kupiłem "taki sam" model i dziś przyszedł. Po podłączeniu do komputera spodziewałem się, że będzie tak samo, jak w poprzednim, ale nie, więc może komuś oszczędzę walki, na którą straciłem dziś dobry kwadrans, jak nie lepiej.

Otóż nowy modem przedstawia się w lsusb:

Bus 002 Device 016: ID 12d1:14db Huawei Technologies Co., Ltd. E353/E3131

Natomiast po wpięciu do portu USB w dmesg widać:

[11264.677637] usb 2-1.2: new high-speed USB device number 15 using ehci-pci
[11264.787001] usb 2-1.2: New USB device found, idVendor=12d1, idProduct=1f01
[11264.787005] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[11264.787007] usb 2-1.2: Product: HUAWEI HiLink
[11264.787009] usb 2-1.2: Manufacturer: HUAWEI
[11264.788426] usb-storage 2-1.2:1.0: USB Mass Storage device detected
[11264.788583] scsi host6: usb-storage 2-1.2:1.0
[11265.736276] usb 2-1.2: USB disconnect, device number 15
[11268.517690] usb 2-1.2: new high-speed USB device number 16 using ehci-pci
[11268.627263] usb 2-1.2: New USB device found, idVendor=12d1, idProduct=14db
[11268.627267] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[11268.627269] usb 2-1.2: Product: HUAWEI HiLink
[11268.627271] usb 2-1.2: Manufacturer: HUAWEI
[11268.630336] cdc_ether 2-1.2:1.0 eth0: register 'cdc_ether' at usb-0000:00:1d.0-1.2, CDC Ethernet Device, 58:2c:80:XX:XX:XX
[11268.707401] cdc_ether 2-1.2:1.0 enx582c80xxxxxx: renamed from eth0

Co prawda świtało mi coś o hilink i zauważyłem kartę sieciową w systemie, ale stwierdziłem, że to tylko jeden z trybów i można używać "po staremu" z /dev/ttyUSB0 i wvdial, który to sposób mam obcykany. Zmyliło mnie też to, że nie mogłem wejść na wskazywany przy opisach wersji hilink adres 192.168.1.1.

Robiłem różne cuda, o których pisać nie będę, na szczęście zapytałem na IRCu i dobrzy ludzie naprowadzili me zawiłe rozumowania na proste tory.

No więc ostatecznie "po staremu" mi się nie udało, natomiast żeby uzyskać adres IP wystarczy wydać polecenie:

dhclient enx582c80xxxxxx

 

I wtedy po wpisaniu w przeglądarkę 192.168.1.1 mamy dostęp do klikalnego interfejsu zarządzania modemem i wszystko działa od kopa.

Niestety, opisy są chyba obliczone albo na ludzi, którzy robią wszystko z ręki, albo na tych, którzy mają wszystko automatycznie. Pobieranie IP z DHCP też.

Wskaźniki jakości łącza

rozieblox

Dumałem trochę nad parametrami łącza internetowego, które abcc mógłby mierzyć, poza tym, komentarze pod wpisem o założeniach abcc trochę pomieszały mi szyki, jeśli chodzi o chronologię, więc najwyższy czas przejść do rzeczy.

Techniczne wskaźniki jakości łącza internetowego to:

  • Opóźnienie - czyli potocznie lag albo ping, zrozumiała chyba dla każdego miara i dość powszechnie używana do określenia, czy łącze jest sprawne. Im jest mniejsze, tym lepiej. Ma znaczenie przy korzystaniu interaktywnym, czyli SSH/remote desktop albo graniu w gry online (zwł. FPP). Niezbyt istotne przy pobieraniu danych czy strumieniowaniu.
  • Straty pakietów - na sprawnym łączu strat nie ma. W przypadku łącz bezprzewodowych lub awarii, straty mogą się pojawiać. Wiążą się z koniecznością retransmisji pakietów lub utratą danych. Mają znaczenie praktycznie wszędzie. Im niższa wartość, tym lepiej.
  • Jitter - zmienność opóźnienia pakietów, czyli dokładniej statystycznie, wariancja opóźnienia pakietów. Ma znaczenie przy korzystaniu interaktywnym, szczególnie przy transmisji głosowej/video. Im niższa wartość, tym lepiej.
  • Prędkość pobierania - określa, jak szybko można pobierać dane. Ważne przy pobieraniu danych.
  • Prędkość wysyłania - określa, jak szybko można wysyłać dane. Ważne tylko przy wysyłaniu większych maili itp.

W wariancie minimum planuję mierzyć tylko dwie pierwsze miary. Waham się nad jitterem - prawdopodobnie kiedyś zaimplementuję, ale wymagałoby zmiany bibliotek i/lub liczenia wszystkiego samodzielnie. Wykonalne, ale na początek mało istotne. Z uwagi na pierwotne zastosowania (GSM) i możliwość opłat za transfer, rezygnuję z badania prędkości pobierania i wysyłania. Zresztą, jest szansa, że same pomiary mogłyby tu wpłynąć na funkcjonowanie łącza, szczególnie słabszego. Dodatkowo wymagany jest host zdalny, udostępniający określoną zawartość (w przypadku downloadu) lub pozwalający na wysyłanie treści (w przypadku uploadu). Nie skreślam zupełnie, ale zdecydowanie nie pojawi się w pierwszej wersji, a jeśli się pojawi, to domyślnie będzie wyłączony.

Na koniec pozostała część zasadnicza, czyli formuła określająca jakość łącza. Ponieważ dla większości parametrów im niższa wartość, tym lepiej, stwierdziłem, że najprościej jest liczyć tylko koszt, czyli sumować "punkty karne", łącze o najniższej wartości "wygrywa". W przypadku dwóch ostatnich parametrów łatwo zamienić je na analogiczne miary - im niższy czas przesyłania znanej ilości danych, tym lepiej.

Ostatecznie na razie wyszło coś takiego:

f(route)= suma(mnożnik_IP * (mnożnik_strat_route * straty_IP + mnożnik_opóźnień_route * opóźnienie_IP))

Dodatkowo całość należałoby przemnożyć przez mnożnik dla danego łącza[1] i wprowadzić, czy to do wzoru, czy przy podejmowaniu decyzji o przełączeniu, koszt przełączenia. Docelowo przydała by się pewnie jeszcze jakaś normalizacja względem ilości IP, żeby dodanie dodatkowych IP do sprawdzania nie powodowało zmiany wartości, bo to zmienia rolę kosztu przełączania. Najprostsza byłaby średnia, ale gryzie się z mnożnikami dla poszczególnych IP. Te z kolei chciałem mieć, bo wyobrażam sobie sytuację, że ktoś chce sprawdzać jakość łącza do różnych IP docelowych, ale niektóre (np. IP firmy) są bardziej istotne przy podejmowaniu decyzji.

Mnożniki dla route wprowadziłem z uwagi na możliwość ustawiania nie tylko routingu domyślnego, ale dla poszczególnych tras. Może się zdarzyć, że do sieci, do której łączymy się przez SSH ruch będzie wysyłany innym łączem, niż podstawowe, ze względu np. na mniejsze opóźnienia. Raczej na wyrost w tej chwili, ale kiedyś pewnie się przyda.

Przechodząc do spraw praktycznych: pobawiłem się chwilę w weekend, jest PoC - czytanie konfiga, część przykładowego konfiga, przepingowanie IP, liczenie kosztu (niedoskonałe). Czekam na zamówiony modem GSM. 56 linii kodu, commit do repo pewnie w tym tygodniu, ale o tym następnym razem. ;-)

[1] Koszt łącza miałby być dodatkowym parametrem, dzięki któremu użytkownik może w jakiś sposób odwzorować parametry pozatechniczne, choćby koszt transmisji za pośrednictwem danego łącza.

Guetzli - lepsza kompresja JPEG

rozieblox

Przedwczoraj Google ogłosiło na blogu nowe narzędzie do kompresji JPEG o nazwie Guetzli, wydawane na wolnej licencji (Apache License). Ma dawać lepsze optycznie rezultaty przy mniejszym rozmiarze wynikowym (mowa nawet o 35% mniejszych plikach). Cena? Oczywiście czas kompresji.

Postanowiłem przetestować na szybko, co mogło by się zmienić, gdybym wykorzystał grafiki skompresowane przy pomocy Guetzli na blogu. W tym celu sięgnąłem po obrazki z backupu bloga i uruchomiłem program (domyślne opcje kompilacji, domyślne ustawienia jakości, czyli 90%) na moim laptopie (CPU: Intel(R) Core(TM) i3 CPU M 380 @ 2.53GHz). Zdziwiło mnie to, że aż przy 12 plikach nie udało się ukończyć działania - program zgłosił błąd:

Invalid input JPEG file
Guetzli processing failed

Udało się przetworzyć 66 plików, całość trwała prawie 17 minut (sic!). Czyli jest bardzo wolno. Kompresor wykorzystywał tylko jeden rdzeń CPU. Efekty są obiecujące, zarówno wizualne, jaki i objętościowe. Mimo, że algorytm jest zaprojektowany z myślą o działaniu na możliwie nieprzetworzonych obrazach wejściowych, a te na blogu raczej są już zoptymalizowane, to łączny rozmiar udało się zmniejszyć o 14% (z ok. 3,3 MB do ok. 2,8 MB).

Jeśli wezmą się za wykorzystanie i optymalizację duże firmy, a jest na to szansa po uwolnieniu programu, może to oznaczać mniej przesyłanych danych po sieci, czyli szybsze ładowanie się stron, widoczne zwłaszcza na komórkach. Chwilowo główną barierą jest czas działania, który wygląda na zależny bezpośrednio od wielkości pliku wejściowego.

Zrobiłem jeszcze jeden test - plik JPG bezpośrednio z aparatu, rozmiar 2560x1440, rozmiar wejściowy 1,2 MB. Po kompresji (trwającej kilka minut) brak zauważalnych zmian jakości, natomiast rozmiar zmniejszony aż o 50% (614 kB).

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