Udostępnianie internetu z telefonu

Niedawno usłyszałem pytanie o setup dla abcc, które zawierało ciekawy element – jedno z dostępnych połączeń było przez USB[1]. Zaintrygowało mnie to, bo tak się złożyło, że zupełnie nie znałem tematu. Zawsze udostępniałem internet z Androida wykorzystując WiFi i tworząc access point. Nie byłem pewien jak takie połączenie w ogóle jest widoczne pod Linuksem.

Poczytałem, sprawdziłem i sprawa jest prosta. Aby udostępnić internet z telefonu z Androidem należy najpierw podłączyć kabel USB. Dopiero wtedy aktywna staje się opcja USB tethering. Po jej aktywacji na telefonie, w systemie powinno pojawić się urządzenie usb0. Traktujemy jak zwykłą przewodową kartę sieciową.

Takie proste, a nigdy nie korzystałem. Czy warto udostępniać połączenie z Androida po USB, zamiast po WiFi? Jedna zaleta jest oczywista – podczas udostępniania połączenia telefon zużywa więcej prądu. Podłączenie kablem do komputera zapewnia od razu ładowanie. Z kolei oczywista wada to mniejsza swoboda ruchów – kabel jest zawsze jakimś ograniczeniem.

Pora sprawdzić wydajność. Szybki zgrubny test, po prostu fast.com, w dodatku pojedynczy pomiar dla każdej konfiguracji.

Operator nr 1
42 Mbps download 10 Mbps upload, latency 32 ms unloaded, 462 ms loaded na WiFi 2,4 GHz
42 Mbps download 15 Mbps upload latency 30 ms unloaded, 420 ms loaded na USB

Operator nr 2 (IPv6)
78 Mbps download 11 Mbps upload, latency 30 ms unloaded 321 ms loaded na WiFi 5 GHz
71 Mbps download 14 Mbps upload, latency 28 ms unloaded 446 ms loaded na USB

Wielkich różnic jak widać nie ma. Wariancie optymistycznym, czyli nieobciążonym łączu na kablu zyskamy nieco na opóźnieniach sieciowych. Lepsze powinien też być upload. Czyli domyślnie warto podłączyć kabel USB. Nie są to jednak wielkie różnice, więc jeśli nie gramy w gry online albo nie zależy nam na prędkości uploadu, wygląda, że może decydować wygoda.

UPDATE I jeszcze dla porównania wyniki z mojej kablówki, nominalnie 60/10:
62 Mbps download 7 Mbps upload, latency 6 ms unloaded 50 ms loaded na WiFi 5 GHz

Oczywiście inny serwer, pomiar dzień później itd. Ale i tak widać, jak bardzo LTE dogoniło, albo wręcz przegoniło kablówkę opartą o miedź. Światłowód zapowiadany był dwa lata temu, ale nadal nic nie wskazuje, by miał się pojawić.

[1] Sprawa w toku, może zasłuży na osobny wpis jak skończę.

Bateria w laptopie

Jakoś tak zeszło ze znajomymi na rozmowę o komputerach. Dokładniej o laptopach wykupionych z pracy. No i mówię, że wszystko fajnie, ale bateria chyba będzie wymagała wymiany u mnie, bo nie trzyma jak dawniej. Oczywiście gdyby laptop był zbudowany jak kiedyś, zwyczajnie wymieniłbym ją i zapomniał o temacie. Jednak teraz zamiast osobnej baterii, którą można wpiąć z zewnątrz, są zabudowane, w środku laptopa. Czyli z prostego wypięcia starej i wpięcia nowej zrobiła się trochę bardziej skomplikowana operacja, co trochę zniechęca.

Tym bardziej, że bateria nadal trzyma tylko… krócej. W zasadzie określenie „trzyma krócej” to nadużycie, bo nie wiedziałem, ile naprawdę trzyma. Zauważyłem, że komunikat o niskim stanie naładowania pojawia się wcześniej. I miałem wrażenie, że nagle. Trochę sfera domysłów, ale po pierwsze raczej rzadko korzystam z tego sprzętu na baterii, a po drugie raczej nie śledzę wtedy stanu naładowania, bo robię coś innego.

Pomiar

W każdym razie rozmowa skłoniła mnie, żeby sprawę zbadać dokładniej. Żeby zobaczyć, ile trzyma bateria, popełniłem szybki skrypt:

#!/bin/bash
OUT='/home/rozie/battery.log'
while :
do
date >> $OUT
acpi >> $OUT
sleep 60
done

Po uruchomienu, co minutę w pliku dodawane są dwie linie. Data i stan baterii. Na przykład:

nie, 30 maj 2021, 19:49:52 CEST
Battery 0: Discharging, 95%, 09:06:51 remaining

Nie jest to idealna wersja do parsowania, ale widać co się działo i kiedy.

Odłączyłem laptopa od zasilania i czekałem. W sumie nie doczekałem się wyłączenia, bo usnąłem. No ale po to właśnie był log.

Okazało się, że laptop działał długo. Stwierdziłem, że do określenia wszystkie wystarczy tak naprawdę sam stan naładowania baterii. W końcu próbki są robione dokładnie co minutę, więc czas będzie znany.

Wynik

Przerzuciłem do CSV i zrobiłem wykres:

Wizualizacja raportowanej pojemności baterii w procentach

Jak widać potwierdziło się wszystko, co mi się wydawało. Bateria trzyma długo, bo prawie 6h. Co prawda to raczej okolice idle, ale nadal sporo, zwłaszcza jak na kilkuletni sprzęt. Widać też, że zgłaszana pojemność gwałtownie spada po ok. 3,5 h.

Czyli jest problem. Szukałem jak go rozwiązać i póki co wyczytałem tylko tyle, że system ma tu niewiele do powiedzenia. Na razie znalazłem taką radę. Rozładowałem do zera, choć miałem opory, bo coś mi się kojarzy, że to niezbyt zdrowe dla baterii. Chyba nie pomogło. Ewentualnie hibernacja coś tu ma do rzeczy.

Za to znalazłem lepsze narzędzie do pomiaru stanu baterii laptopa w czasie. Battery-stats, bo o nim mowa, jest ładnym rozwinięciem prostej idei z powyższego skryptu dostępnym w repozytoriach Debiana. Jest i porządny plik, czytelny dla człowieka, i skrypt w bashu, który z pomocą gnuplot generuje wykres.

Gdyby ktoś miał pomysł, jak sprawić, aby cały czas pokazywana była rzeczywista pojemność i pozostały czas pracy, chętnie przyjmę rady. Wymieniać nie będę. Nawet gdybym miał wyłączać laptopa po tych 3,5 h, to w zupełności mi to wystarcza.

Automatyczne aktualizacje Debiana – HOWTO

Utrzymywanie aktualnych wersji oprogramowania to podstawa bezpieczeństwa. Nawet w przypadku zwykłego desktopa ma to znaczenie, szczególnie jeśli chodzi o przeglądarki internetowe. Pomóc w tym mogą automatyczne aktualizacje pakietów.

Tradycyjna, ręczna aktualizacja oprogramowania w Linuksie sprowadza się w większości dystrybucji do odświeżenia listy dostępnych pakietów i zainstalowania nowych wersji. Dla dystrybucji opartych o pakiety deb będzie to
apt-get update; apt-get dist-upgrade[1]

W dystrybucjach Linuksa takich jak Debian czy Ubuntu do dyspozycji mamy unattended upgrades, czyli mechanizm pozwalający na automatyczne aktualizacje pakietów. Pozwala on aktualizować wskazane pakiety bez ingerencji zarówno użytkownika, jak i administratora systemu. Poza samą aktualizacją umożliwia skonfigurowanie dodatkowych warunków, jak praca tylko przy podłączonym zasilaczu, wymuszenie rebootu systemu po aktualizacji pakietów, ograniczenie pasma przeznaczonego na pobieranie aktualizacji czy sprzątanie starych wersji kernela.

Aby włączyć mechanizm automatycznych aktualizacji, trzeba zainstalować pakiet unattended-upgrades. Dodatkowo należy wyedytować plik konfiguracyjny:
cat /etc/apt/apt.conf.d/20auto-upgrades
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Samą konfiguracją działania automatycznych aktulizacji sterujemy przy pomocy zawartości pliku
/etc/apt/apt.conf.d/50unattended-upgrades.

Opcji jest wiele, od tego, które pakiety wykluczyć z aktualizacji, przez raportowanie mailem, czy wspomniane wcześniej limitowanie szybkości pobierania aktualizacji czy reboot systemu. Domyślna zawartość powinna być OK, jeśli korzystamy wyłącznie z podstawowych repozytoriów. W przypadku posiadania dodatkowych źródeł pakietów, warto sprawdzić czy będą one także aktualizowane i w razie potrzeby dostosować plik.

Przetestować działanie wprowadzonych zmian i ogólnie zachowanie możemy poprzez wydanie polecenia
unattended-upgrades -d

Pokaże ono, które pakiety zostałyby zaktualizowane w naszym systemie.

Trzeba pamiętać, że tego typu nienadzorowana aktualizacja zawsze niesie jakieś ryzyko niepowodzenia. Osobiście korzystam od lat na paru desktopach i nie napotkałem problemów. Jest tam jednak Debian w wersji stabilnej, przeważają repozytoria standardowe, a z dodatkowego oprogramowania są jedynie przeglądarki.

Na koniec polecam lekturę tego opisu automatycznych aktualizacji. Znajdziecie tam wiele dodatkowych szczegółowych informacji i przykładów.

[1] Dostępna jest też mniej inwazyjna wersja polecenia czyli apt-get update. Próbuje ona aktualizować tylko te pakiety, których aktualizacja nie wiąże się z usuwaniem ani doinstalowaniem innych pakietów. Ceną jest pozostawienie w dotychczasowej wersji pakietów, których nie da się zainstalować bez tej operacji. Więcej w manualu apt. Interesującym narzędziem do zarządzania pakietami jest opisywany kiedyś wajig.