Blog domo

Od jakiegoś czasu borykałem się ze sporym problemem- zawieszającym się serwerem, na którym zainstalowany jest Debian. Dziś w końcu (mam nadzieję) odkryłem tego przyczynę. Wcześniej nie znajdowałem uzasadnienia tych wybryków systemu, bo z komputerem miałem styczność dopiero w momencie, gdy już system całkowicie nie odpowiadał, a w logach była zupełna pustka.

Okazało się, że problem dotyczył acpi i procesów kacpid i kacpi-notify, które dosłownie pożerały zasoby systemowe- wykorzystanie procesora ponad 90%. Po kilku minutach system zawieszał się i nic się nie dało zrobić. Tym razem problem był o tyle nieciekawy, że po resecie komputera od razu działo się to samo, a samych procesów „zabić” się nie udawało. Spędziłem sporo czasu na szukaniu rozwiązania problemu, ale nic sensownego w google nie znalazłem, poza utwierdzeniem się w przekonaniu, że jest to jakiś większy bug.

Niestety, jedyne co mogłem zrobić w tej sytuacji, to zmodyfikować skrypty startowe, aby acpid nie uruchamiał się przy bootowaniu  oraz dorzuciłem do gruba wpis „acpi=off”. Z racji tego, że mam grub2, musiałem sprawdzić gdzie to dodać, bo gruba2 mam od niedawna i jeszcze nie poznałem go zbyt dobrze.

modyfikujemy: /etc/default/grub
dodając:  GRUB_CMDLINE_LINUX=”acpi=off”
na koniec: update-grub2

Wolałbym rozwiązać ten problem w inny sposób, ale na szczęście w moim przypadku nie ma tragedii, bo acpi na tym kompie nie potrzebuję.

linux, sprzęt cpu, debian, kacpi-notify, kacpid, system freeze

Tuż przed wyjazdem na urlop, dosłownie jakieś 2h przed zjawieniem się na lotnisku, rzutem na taśmę odebrałem nowy telefon, na który swoją drogą „chwilę” poczekałem… Warto było.

Skupię się póki co na jednej rzeczy związanej z telefonem, rzeczy która dość znacznie zmniejszyła moje wydatki na połączenia wychodzące z zagranicy oraz tak naprawdę wpłynęła, na możliwość dzwonienia momentami bez zwracania uwagi na koszty. Resztę aspektów związanych z telefonem opiszę później.

Dość szybko znalazłem w Markecie (darmową) aplikację, która umożliwia wykonywanie połączeń przez VOIP, a dokładniej przez protokół SIP. Aplikacja nazywa się Sipdroid i w zasadzie jest pierwszą i jedyną, którą do tej pory przetestowałem, ale mogę powiedzieć, że spisuje się co najmniej zadowalająco. Po zainstalowaniu aplikacji i wpisaniu danych serwera VOIP, dodaniu konta użytkownika, zmieniłem jedną rzecz w opcjach zaawansowanych- włączyłem opcję „używaj serwera STUN„. Bez tej opcji miałem problemem z wykonywaniem połączeń. No i działa :). Potem wystarczyło znaleźć niezabezpieczoną sieć np. w Maroku, albo taką o której ktoś myślał, że jest zabezpieczona i można było dzwonić do PL na stacjonarne za 5 groszy lub na  komórkę za 35 groszy :-).

Czasem bywały co prawda problemy z działaniem programu i podejrzewam, że było to związane ze STUN, bo zdarzało się że jedna ze stron nie słyszała drugiego rozmówcy, ale miało to miejsce na tyle rzadko, iż uznaję to rozwiązanie i tak za świetne. Hmmm, a tak naprawdę to świetny jest Android i Linux ;). Co do softu, to jak będę mieć więcej czasu, to może uda mi się znaleźć bardziej niezawodny. W każdym razie rozwiązanie Android vs. VOIP (SIP) to bez wątpienia totalna rewelacja w ograniczeniu płatności za telefon.

linux, wyjazd Android, SIP, sipdroid, tanie połączenia, VOIP

Dokumentacja proftpd? Wyniki z google? Wszystko nieaktualne… W końcu znalazłem „dyrektywę” do proftpd.conf, która ograniczy pasmo w taki sposób jak tego chcę.

TransferRate RETR 9200:0 ##92Mb/s
TransferRate STOR 9000:0 ##90Mb/s

Potrzebowałem tego właśnie- zrobić limit na download i na upload(zapis) na serwerze ftp. Działa.. Ehhh, tylko czemu dokumentacja jest taka popieprzona?

linux download, proftpd, transfer limit, transfer ratio, upload

Już jakiś czas temu zwróciłem uwagę na to, że transfer danych pomiędzy moim laptopem a AP Dl-524 jest dość niski w porównaniu do tego jakie maksymalne możliwości posiada łącze internetowe, z którego korzystam.

Mocno zauważalne stało się to po zmianie szyfrowania sieci na WPA- maksymalny download wynosił ok 10-11Mb/s. Sądziłem że to wina spartolonego WPA w linuksowym sterowniku ath9k, ale pod Windowsem transfery były niewiele wyższe. AP nie jest umieszczony w jakimś szczególnie zabudowanym miejscu i w sporej odległości, więc nie znajdowałem wytłumaczenia tego stanu. Winę zrzuciłem na AP/ kartę sieciową w laptopie.

Wczoraj stwierdziłem, że poszukam  jakiegoś nowszego firmware dla Dlinka, gdyż obecne było nieco archaiczne- bodajże 2004 i udało mi się natknąć na wersję z 2008- v.2.07.
Zaktualizowałem firmware i… okazało się że nastąpiła diametralna poprawa transferu- teraz spokojnie dochodzi do 16-18Mb/s, co jest co prawda mniejszą wartością aniżeli parametry mojego łącza, ale i tak daje to powody do zadowolenia.

Na chwilę obecną nie zmieniam AP, ale gdy zmienię łącze na szybsze (co planuję), to jednak przydałby się inny AP Router, który będzie działał w standardzie n, tak jak moja karta w lapku… Głupio byłoby mieć w  takiej sytuacji łącze 50Mb :)

Link do firmware v.2.07

linux, sprzęt 2.07, Dl-524, firmware, upgrade

Po bardzo długim okresie czasu bez jakiejkolwiek aktualizacji, pojawiła się 16.11.2010 nowa wersja NiceShapera-  0.6rc7. W changelogu zbyt wiele informacji nie ma, ale jedno mogę powiedzieć- zauważyłem zmiany na lepsze.

Po aktualizacji Debiana i oczywiście kernela, okazało się że NiceShaper ześwirował i w bliżej nieodgadnięty sposób drastycznie ograniczał transfer. Po zaktualizowaniu do nowej wersji kształtowanie ruchu powróciło do optymalnego stanu.

linux niceshaper, nowa wersja