Pomysł

Niedawno Ministerstwo Infrastruktury wpadło na pomysł kolejnej regulacji. W skrócie, tym razem sprowadza się to do: jeśli komuś Internet działa, ale z prędkością niższą niż 90% maksymalnej określonej w ofercie, przez 12h lub dłużej w skali miesiąca, to ten ktoś nie płaci rachunku za Internet za dany miesiąc. Interesujące, prawda? Pomysł jest tak skandalicznie zły, że nie mogę go zmilczeć. No to po kolei (bardziej ze strony ISP, bo jest mi jednak bliższa, choć i klientem jestem):

Problem istnieje

Nie ma co ukrywać, że biznes w dostarczaniu Internetu klientom indywidualnym opiera się na kupnie większej ilości pasma i skorzystania z tego, że nie wszyscy korzystają jednocześnie (czyli tzw. overbooking lub overselling). Jednak żaden normalny ISP nie oferuje z premedytacją prędkości takich, których w normalnych warunkach nie jest w stanie zapewnić. Chyba, że na danym obszarze nie ma konkurencji... Co innego operatorzy komórkowi (kto osiąga reklamowane 7,2Mbps)? U nich nawet rozmowy telefoniczne są overbookowane. Wystarczy spróbować zadzwonić w Sylwestra, by się o tym przekonać...

Jasne, trzeba klientów chronić przed nieuczciwymi praktykami typu: na łączu 10 Mbps jest 30 klientów po 10 Mbps. Czy też nawet 3 klientów z abonamentem 10 Mbps. Ale 30 z abonamentem 1 Mbps? Co miałoby źle działać (i jak często)? Ale czy na pewno w ten sposób? Zgadzam się, że klient powinien być zwolniony z "lojalki", powinien posiadać możliwość rozwiązania umowy lub otrzymać rekompensatę, jeśli problem z prędkością występuje, ale nie na takich zasadach, jak proponowane.

Źródła niskiej prędkości

Dostęp do Internetu składa się z następujących składników:

• Infrastruktura po stronie klienta. Komputer, router, modem, połączenia między sprzętami (potencjalnie źle skonfigurowane wifi, poniszczone kable).
• Infrastruktura po stronie dostawcy: kable, światłowody, radia, switche, routery, modemy (potencjalnie poniszczone kable, zakłócone radia, błędy konfiguracji).
• Infrastruktura po stronie pośredników - zasadniczo podobna jak u dostawcy - w końcu dostawca jest dla nich klientem. Osobno, bo ISP nie ma wpływu na jej funkcjonowanie (poza wyborem operator X lub Y).
• Infrastruktura po stronie dostawcy treści - routery, switche, serwery, aplikacje. Dodatkowo możliwość nakładania limitów różnej maści (choćby ograniczanie prędkości per połączenie czy per IP; wiele różnych błędów możliwych).

Problem jest z jednoznacznym pomiarem (samym pomiarem! bo co to tak naprawdę jest prędkość Internetu?), problem jest też z jednoznacznym określeniem źródła problemu (często jest to właśnie sprzęt w domu klienta). Wszystkie elementy każdej powyższej infrastruktury (klient, ISP, operatorzy pośredni, dostawca contentu) mają realny i znaczący wpływ na ostateczny wynik. Dlaczego każe się ISP dostarczającemu usługę klientowi indywidualnemu odpowiadać za infrastrukturę w domu klienta, u dostawców pośredniczących i u dostawcy treści? I czemu karze się go za błędy nie leżące po jego stronie? Bo do tego się ten projekt sprowadza.

Wartości

Sama wartość 90% prędkości jest wartością wysoką. Skrajnie wysoką. Rozumiałbym 1% czy też nawet w porywach 10%, ale nie 90%... Podobnie 12h - jest to wyśrubowane wymaganie. 1,6% czasu. Nawet przy łączach operatorskich i całkowitej awarii (zupełny brak działania łącza, chociaż często znacznie niewystarczająca prędkość jest traktowana jako awaria) przez taki okres czasu, niekoniecznie jest upust 100%. Przy wprowadzeniu zapisów proponowanym kształcie może okazać się, że państwo będzie narzucało operatorom świadczenie usługi z parametrami wyższymi, niż sami mają szansę ją zakupić. Jasne, ISP może (i większość to robi) korzystać z więcej niż jednego operatora, by niwelować skutki awarii. Tylko, że to kosztuje. I w sumie Kowalski- jeśli mu bardzo zależy - może sobie kupić redundantne łącze, którego będzie używał w czasie awarii (no dobrze, kto ma 2 niezależne łącza w domu? ja nie, jeśli nie licząc drogiego i wolnego dostępu przez komórkę...).

Pamiętać też trzeba o tym, ilu ludzi potrzebnych jest do obsługi łącz operatorskich, żeby zmieścić się w SLA i przywrócić usługę w pojedyncze godziny. Mówimy o pracy 24/7, dyżurach itd. stosunkowo dużej ilości ludzi w przeliczeniu na ilość łącz/urządzeń. Ilu "techników" byłoby potrzebnych, żeby dotrzeć do Kowalskiego do domu w przypadku (realnego) problemu w ciągu pojedynczych godzin? Jak wpłynęłoby to na cenę usługi? Ktoś w ministerstwie ma pojęcie, ile kosztuje megabit na warunkach operatorskich?

Niezależnie od proponowanej wartości (czy będzie to 1, czy 10, czy 90%) pozostają kwestie problemu technicznego wykonania rzetelnego pomiaru (zwł. określenia do czego mierzyć) oraz kwestie prawne, do których dojdę.

Technologia

Wygląda, że Ministerstwo Infrastruktury wykazało się też sporą nieznajomością technologii, którą się nadzoruje. Proponuję przedstawicielom wybrać się na prezentację dowolnego profesjonalnego (operatorskiego) sprzętu radiowego posłuchać, jak to działa i co dzieje się z pasmem (i w jakim zakresie) przy pogorszeniu się warunków transmisji. Proponuję też poczytać trochę o mechanizmach QoS, przyjąć do wiadomości istnienie ruchu klasy "best effort" itd. Oraz zapoznać się u operatorów, jakie procentowe wartości pasma ustawiane są jako gwarantowane (i czemu nie jest to 90%), dla jakich klas itd.

W tej chwili proponuje się stawianie całego funkcjonowania sieci (i paru pokrewnych nauk związanych z prognozowaniem i modelowaniem) na głowie. Danie klientowi indywidualnemu gwarancji pasma, na dodatek rzędu 90% kłóci się ze wszelkimi szkołami, skazuje na niebyt technologię radiową i powoduje, że mechanizmy QoS przestają mieć sens, bo i tak trzeba (a na pewno jest taniej) projektować sieć na 100% możliwego ruchu (powiedzcie to telefonistom, pękną ze śmiechu). Operator zamiast z punktu A do punktu B mieć dwa niezależne łącza wysycone po 70% (i w przypadku całkowitej awarii jednego z nich świadczenia usługi z zaniżoną prędkością), będzie miał jedno. Przecież i tak nikt nie zapłaci za czas awarii, więc po co płacić za drugie łącze? Szybsze w jednym przebiegu będzie tańsze.

Kwestie prawne

Moim zdaniem, Ministerstwo Infrastruktury ma chrapkę na totalną kontrolę rynku i chce jej funkcjonowania poza istniejącymi przepisami prawa, bez oglądania się nawet na możliwości techniczne. Pod hasłem ochrony odbiorców z jednej strony chce kontroli nad ISP, ale pod innymi hasłami chce kontroli nad użytkownikami (retencja danych, cenzurowanie stron). Oczywiście nie za swoje pieniądze. A przecież w opisywanym problemie z prędkością wystarczyłoby skorzystać z istniejących ogólnych przepisów i możliwości prawnych typu niezgodność towaru z umową, klauzule niedozwolone itp. Skąd zatem nieobecne w aktualnym prawie "nie podoba mi się, to nie płacę", wyłączenie sądów i skazywanie ISP na (nie)łaskę użytkowników? Nie lepiej skupić się na egzekwowaniu istniejących zapisów prawnych i kontroli stanu faktycznego? Pewnie nie, bo wymagałoby to pracy urzędników...

PS. UKE chce w maju debaty na ten temat. Patrz Message-ID: fed39d94-4325-403b-a6c7-81aa770f4b6f@u3g2000vbe.googlegroups.com W URL jest (i będzie), że pomysł jest UKE, nie MI, co nie jest prawdą - nie we wszystkich miejscach poprawiłem od razu i... zostało.

Ponieważ system po nieudanej aktualizacji już działa (w ogóle okazało się, że przyczyną "problemów z grubem" była w rzeczywistości najprawdopodobniej niedociśnięta taśma od stacji dysków) i mogę dostać się do swoich danych, to pora na konkrety i przestrogę.

Komunikat, który mówił o problemach z przejściem na dependency based boot przy upgrade z Lenny'ego do Sarge Squeeze i który może nie tyle zignorowałem, co chciałem zająć się nim po reboocie (bo zapisałem) wyglądał dokładnie tak:

Unable to migrate to dependency-based boot system

Tests have determined that problems in the boot system exist which prevent migration to
dependency-based boot sequencing:

insserv: warning: script 'K20atieventsd' missing LSB tags and overrides, insserv: warning: script
'atieventsd' missing LSB tags and overrides,

If the reported problem is a local modification, it needs to be fixed manually. If it's a bug in the
package, it should be reported to the BTS and fixed in the package. See
http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot for more information about how to fix the
problems preventing migration.

To reattempt the migration process after the problems have been fixed, run "dpkg-reconfigure sysv-rc".

Skrypt atieventsd pochodzi z flgrx, z którego nie korzystałem od migracji na Lenny'ego. Taka zemsta ATI/AMD zza grobu.

Ale co sobie powalczyłem, to powalczyłem (kolejne sprawności zdobyte: instalator nie jest taki świetny i ma głupie defaulty dla instalacji gruba - kto to widział, że przy instalacji wszystkiego na sdb i niczego na sda chce umieścić gruba na sda?; rescue mode daje radę). Okazało się, że CD-ROM też już nie działa - zasilacz od dawna był słaby i miał problemy z kręceniem dwoma dyskami, ale teraz doszło do tego, że i jednym nie kręci, jeśli CD-ROM jest podpięty. No chyba, że stacja dyskietek tak bruździła. Nie wiem, nie wnikam, działa - nie dotykam (ładne rymowane motto, swoją drogą).

UPDATE: Inna możliwa przyczyna, to własny - a nie dystrybucyjny - kernel. Dziś kolejna osoba miała problem ze swoim kernelem na Squeeze, identyczne objawy (pusty /dev), a na dystrybucyjnym działało OK. Instalacja linux-image-2.6-amd64 (lub linux-image-2.6-486 dla systemów 32-bitowych) przed rozpoczęciem upgrade'u do Squeeze wydaje się dobrym pomysłem. ;-) Zresztą jest to opisane w release notes procesu aktualizacji Lenny do Squeeze (wersja robocza; TBH nie czytałem przed aktualizacją - nie wiem czy był już dostępny - mea culpa).

Minęły prawie 2 lata odkąd zrobiłem upgrade tej maszynki do Lenny'ego. Stwierdziłem, że Squeeze, którego używam od dłuższego czasu jest dobry, przydałoby się parę nowych pakietów no i można przetestować jak ten upgrade wychodzi. KDE 3.5 też jakoś nie jest tym, co mi ostatnio pasuje (a pasuje mi LXDE), więc stwierdziłem, że parę dni wolnego to dobry moment, żeby zrobić upgrade.

Problem numer jeden, który uniemożliwił mi zalecaną wersję upgrade'u, to za mała ilość wolnego miejsca. 1 GB wolnego na /, po porządkach 1,3 GB. Zdecydowanie nie to, co tygrysy lubią najbardziej. Postanowiłem, że po prostu podmienię wpisy w sources.list z lenny na squeeze, zrobię wajig update; wajig upgrade a następnie wajig dist-upgrade. Wcześniej wywaliłem jeszcze javę i OpenOffice. Gołe dist-upgrade niestety nie mieściło się.

Update poszedł bez problemu, po nim kontrolny reboot. Wszystko ładnie działa. Pora zatem na dist-upgrade. Ten też w zasadzie przebiegł bezproblemowo. Jedyne co pojawiło się z dziwnych rzeczy, to ostrzeżenie, że nie może korzystać z dependency based boot, które skrypty przeszkadzają i gdzie szukać pomocy. Oczywiście zapisałem sobie te komunikaty, dałem OK. Update się zakończył, pora na reboot.

I tu zaczęły się schody. Przy próbie montowania /home z osobnej partycji, stwierdził, że /dev/hda3 nie istnieje i zaproponował uruchamianie w maintaince mode. Hm! Stwierdziłem, że pewnie kwestia kernela (mam własny), więc doinstaluję dystrybucyjny. Prawie się udało, niestety grub nie chciał się zaktualizować - brak dysków w /dev. Faktycznie ich nie było. Trochę powalczyłem ze skryptami startowymi, które były prawdziwą przyczyną zamieszania (bez większych sukcesów, namierzyłem jedynie nieuruchomiony hald) i stwierdziłem, że skoro / jest na osobnej partycji, to najszybciej będzie zainstalować system debootstrapem. Przy okazji zmigruję z ext3 na ext4.

Tylko jak uruchomić debootstrap, jeśli USB jest nieczynne (dziękujemy padniętym kondensatorom na płycie), a live nie ma? Przełożę dysk! Tak też zrobiłem. Niedługo później system był zainstalowany. Teoretycznie, bo aktualnie przy wejściu do gruba wykonuje malowniczy reboot.

Właśnie ściągam płytę instalacyjną. Mam nadzieję, że nagrywarka i czytnik są sprawne i że po zainstalowaniu instalatorem będzie się bootował.

Podsumowując: mam dość upgrade'ów, a konkretnie żonglowania sprzętem, na dłuższy czas, a już na pewno nie na sprzęcie, gdzie w prosty sposób nie można odpalić live. Najlepiej z USB.

Z programów napisanych w Javie korzystam raczej rzadko (wyjątkiem jest bloxer2, którym od dłuższego czasu wrzucam tu wpisy), więc nie zauważyłem tego wcześniej. Debian w wersji Squeeze, Java z repozytorium (wersja 6.20-dlj-1).

Jedna ze stron nie mogła załadować appletu i rzucała:

load: class VncViewer.class not found

[różności] 

Caused by: java.net.ConnectException: Network is unreachable

Ta sama aplikacja nie działała wcześniej na samodzielnie robionej Javie od Sun, z kolei działała (i nadal działa) na różnych wersjach Javy w Debianie Lenny. Na szczęście coś mi świtało, że ogólnie jest problem z IPv6 w Javie, szybkie gógiel potwierdził, więc pozostało znalezienie, co trzeba zmienić. Dobrzy ludzie z IRCa pomogli (!java ipv6), więc przybliżę rozwiązanie.

Winne jest zmienione domyślne ustawienie dla IPv6 w Debianie Squeeze. Okazuje się, że błąd jest zgłoszony, a działanie sieci pod Javą przywraca (tzn. w części aplikacji, niektóre działają bez problemu) ustawienie w pliku /etc/sysctl.d/bindv6only.conf:

net.ipv6.bindv6only = 0

Od jakiegoś czasu chodził za mną zakup prywatnego laptopa. Nie stacjonarki (taką bym miał od ręki), bo nie mam tyle miejsca w domu. Poza tym, stacjonarki hałasują, żrą kupę prądu, wymagają klawiatury i monitora (wspominałem o braku miejsca?), nie mają wifi (kable... wspominałem o braku miesca?) ale czegoś małego, łatwego do zwinięcia ze stołu, spakowania w plecak i przewiezienia. Służbowy laptop niby jest, ale to nie to samo (nie zepsuję sobie systemu do poziomu niedziałania czy filesystemu do poziomu utraty danych), poza tym, trzeba to nosić do pracy i z pracy...