Apt-p2p – ostateczny test

Krótko o apt-p2p

Apt-p2p spodobał mi się od razu, gdy tylko o nim usłyszałem. Jest to bardzo ciekawe podejście, w którym pobieranie pakietów deb odbywa się przy pomocy P2P (protokół bittorrent), zamiast z tradycyjnych centralnych repozytoriów (HTTP, FTP). Centralne repozytoria są wykorzystywane wyłącznie w przypadku, kiedy pakiet nie jest dostępny przez P2P lub nie jest wystarczająco popularny (za mało peerów).

Kiedyś zrobiłem krótki test apt-p2p, ale trudno go nazwać miarodajnym – maszyna była bardzo słaba, demon ma spory apetyt na zasoby i nie udało mi się wtedy zmusić go do działania jako proxy dla innych maszyn, a sam test nie trwał długo. Od tamtej pory minęło trochę czasu. Maszynka robiąca za router została wymieniona na coś bardziej współczesnego, znalazłem sposób na uruchomienie apt-p2p jako lokalnego proxy (brzydki, bo wymaga gmerania w kodzie, ale się da i działa). Program dostał drugą szansę.

Efekty działania

Demon był testowany (czyli po prostu używany) w sumie na trzech maszynach, przez parę tygodni. Pierwsza maszyna, działająca 24/7, w zasadzie base system + parę pakietów, Lenny, publiczne IP, robiła też za proxy dla kolejnej (desktop, Lenny). Apt-p2p w wersji 0.1.5:

Transport

Mirror DownloadsPeer DownloadsPeer Uploads
This Session0.0B0.0B0.0B
Session Ratio0.00%0.00%0.00%
All-Time108MiB32.5MiB50.4MiB
All-Time Ratio76.85%23.15%35.86%

Maszyna druga (mój desktop), Squeeze, za NAT, bez przekierowanych portów. Apt-p2p w wersji 0.1.6:

Transport

Mirror DownloadsPeer DownloadsPeer Uploads
This Session47.4MiB119KiB0.0B
Session Ratio99.75%0.25%0.00%
All-Time1.07GiB340MiB0.0B
All-Time Ratio76.33%23.67%0.00%

Statystyk trzeciej maszyny nie zaprezentuję – napotkałem na dziwny problem z pobieraniem plików, być może mający związek z uruchomieniem tunelu IPv6 (MTU? brak wsparcia dla IPv6 w apt-p2p?) i cache był czyszczony przy okazji prób rozwiązania problemu. Jak patrzyłem wcześniej, to nic specjalnie różniącego się od powyższych nie zauważyłem.

Inne uwagi

Pierwsze, co rzuca się w oczy po zmianie sposobu pobierania, to fakt, że pobieranie jest znacznie wolniejsze, niż normalnie. Widać to szczególnie na szybszych maszynach, z lepszym łączem. Prawda jest taka, że zwykle z tradycyjnych repozytoriów pakiety lecą z pełną prędkością. W przypadku skorzystania z apt-p2p widać przy każdym pliku laga, zapewne chodzi o sprawdzanie, czy peery posiadają dany pakiet. Nie jest to drastyczne dla aktualizacji systemu, ale drażni, jeśli potrzebujemy szybko doinstalować jakiś pakiet.

Jeśli chodzi o pobieranie, to jak widać na tej mizernej próbce, stosunek pakietów pobieranych tradycyjnie do pobieranych przez P2P jest w miarę stały i wynosi około 3 do 1. Całkiem niezły wynik, szczerze mówiąc liczyłem na znacznie mniej pobieranych przez P2P.

Widać też wyraźnie, że przekierowanie portu jest absolutnie niezbędne, jeśli nie chcemy być leecherem. Szczerze mówiąc, liczyłem, że coś tam będzie się wysyłać zza NAT do peerów z publicznym IP, tak jak przy tradycyjnym P2P, ale widocznie implementacja protokołu niestety nie pozwala na to.

Pakiet ma sporo błędów, a autor nie spieszy się z ich usunięciem. Wspomniany wcześniej brak prostego sposobu na uruchomienie apt-p2p jako lokalnego proxy to jeden z przykładów. Do tego dochodzą nieciekawe defaulty związane z miejscem zajmowanym przez logi czy problemy z działaniem przy zmianie IP lub utracie łączności z Internetem.

Na szybką poprawę błędu związanego z możliwym DDoSem przez klientów P2P też pewnie nie ma co liczyć… Nawet nie zgłaszałem tego, bo na inne błędy zero reakcji autora. Taki brak odpowiedzi jest okrutnie demotywujący, fajnie jest usłyszeć choćby, że będzie poprawione w następnej wersji, albo że nie uważa tego za (poważny) błąd.

Ewidentnie brakuje silnego community wokół projektu, najlepiej ze znajomością Pythona (przyznaję, próbowałem nieco z powyższych poprawić przez dodanie opcji, ale prawda jest taka, że ciężko i długo robi się coś w języku, którego się nie zna).

Zapewne wszystko wiąże się z tym, że apt-p2p jest mało popularny. Widać to choćby na kanale IRC poświęconym programowi. Zapewne prędkość pobierania byłaby wyższa, gdyby peerów było więcej, pewnie udałoby się poprawić część błędów, a autor miałby większą motywację do pracy widząc, że program jest popularny.

Podsumowanie

Uważam, że w tej chwili apt-p2p jest mocno zapuszczony, słabo przetestowany i IMHO nadaje się wyłącznie dla geeków. Jeśli są chętni (najlepiej ze znajomością Pythona) do zabawy z tym programem, to dajcie znać. Jest dobry moment na popularyzację tego rozwiązania, przy okazji pewnie dałoby się odciążyć nieco mirrory przy wydaniu Squeeze’ego (i zapewnić szybszy upgrade do nowego systemu – tak przynajmniej twierdzono w swoim czasie w przypadku Ubuntu). Jeśli chętnych brak, to nie pozostaje nic innego, jak wyłączyć apt-p2p i znowu poczekać parę lat… Może coś się zmieni.

Jak nie szukać pomocy (na IRC).

Co prawda dotyczy IRC, ale przypuszczam, że dla różnego rodzaju forów będzie prawdziwe. Oto krótki przepis, jak nie szukać pomocy w Internecie (zwł. IRCu):

  1. Wejdź na kanał poświęcony jakiejś dystrybucji.
  2. Pochwal się, że własnoręcznie zrobiony kernel nie działa.
  3. Zapytaj dlaczego?
  4. Oświadcz, że UUID są do niczego.
  5. Zapytaj czego nie wkompilowałem?
  6. Oświadcz, że na kernelu dystrybucyjnym działa, ale jest on do niczego, bo coś innego nie działa, a poza tym własny kernel jest boski i überzoptymalizowany.
  7. Nie podawaj żadnych szczegółów nt. niedziałania czegoś innego, w szczególności – mimo próśb – nie podawaj opcji w swoim kernelu, które sprawiają, że działa.
  8. Zaproponuj twierdzącym, że jednak coś innego powinno działać, żeby sami uruchomili coś innego, totalnie im niepotrzebnego.
  9. Oświadcz pomagającym, że nie umieją (chociaż im działa, także na własnym kernelu) i nie jesteś jasnowidzem, żeby wiedzieć, czemu Twój kernel nie działa, bo nie wiesz co się pozmieniało między wersjami dystrybucji.
  10. Wklej linka do bug reporta, gdzie jest fragment z logów, gdzie jak wół stoi, którą opcję trzeba zmienić przy kompilacji.
  11. Oświadcz, że nie czytasz release notes.
  12. Powiedz pomagającym, że są irytujący, zapytaj ich, czy wydaje im się, że są Linux guru i wiedzą, co jest dobre a co złe.
  13. Zaproponuj opisanie sytuacji na blogu.
  14. Nie dziękuj i wyjdź.

W razie wątpliwości: marudź, nie odpowiadaj na pytania lub rób to wymijająco, nazywaj rozwiązania stosowane w dystrybucji głupimi. Przecież wiesz lepiej. Jak najczęściej pytaj dlaczego nie działa?, konkrety podawaj tylko w ostateczności.

MSPANC

Optymalizacja MPD.

Jakiś czas temu znalazłem coś, co uważam za ostateczne rozwiązanie dla muzyki pod Linuksem. Ale, po pewnym czasie używania, stwierdziłem, że coś to MPD za duży apetyt ma na procesor. Przypomniał mi o tym sirmacik przy problemach z „charczącym” dźwiękiem, których powodem była różna częstotliwość muzyki i karty. Konkretnie – odtwarzanie Radio Baobab owocowało zużyciem procesora ok. 8-12% wg top (strumień ogg). Niby żaden dramat, bo laptop demonem szybkości nie jest, ale szybki test na mplayerze pokazał, że jemu wystarcza 3-5%.

Oczywiście mplayer to inna bajka – ma wykrywanie procesora podczas uruchomienia, a MPD takich wodotrysków niestety nie ma (strumienia PR 3, czyli Trójki też nie umie odtworzyć, niestety Trójka działa w MPD, wymagany odpowiedni format źródła i odpowiednia wersja MPD – w 0.15.12-1.1 nie działało, mimo zmiany formatu, w 0.15.15-2 z Debiana unstable działa). Zaczął się więc debug. Po pierwsze, trafiłem (nie po raz pierwszy) na świetną stronę opisującą tuning MPD. Po wypróbowaniu wszystkich praktycznie wszystkich sposobów na wyłączenie resamplingu, po braku jakichkolwiek efektów, byłem gotów na przekompilowanie MPD i bibliotek z włączeniem optymalizacji na PIII (bo karta – tania karta USB – uparcie działała w 48 kHz), ale…

Drugiego dnia dobrzy ludzie na IRCu zwrócili moją uwagę na niepozorny i zdecydowanie niewyeksponowany w owym czasie (czytaj: słowa o nim nie było) na wspomnianej stronie parametr samplerate_converter. Okazało się, że jest obecny i opisany w konfigu (cóż, tam nie szukałem, skoro jest dedykowana strona o tuningu). Okazało się, że po dodaniu w konfigu linii:

samplerate_converter            "internal"

MPD zużywa dokładnie tyle procesora, co mplayer – 3-5%. Różnica w jakości jest słyszalna, ale jeśli ktoś słucha głównie radia internetowego, na słabym sprzęcie audio i nie na słuchawkach to spokojnie i bezboleśnie daje się słuchać. Jeśli ktoś ma słaby sprzęt lub nie ma koprocesora, to wręcz nie ma wyboru. 😉

PS. Oczywiście dopisałem stosowny fragment na ww. wiki, w sumie wypada od tego zacząć, żeby sprawdzić, czy o resampling chodzi… Nawiasem, jeśli jest problem z dźwiękiem pod Linuksem, szczególnie w mpd czy mplayerze – przerywa, harczy, tnie, to prawdopodobnie też kwestia ustawień resamplingu. Ww. strona na wiki podaje przyczynę i sposoby rozwiązania.