Forum Debian Users Gang

urug napisał(-a):

To Ty tu jesteś specjalistą od QoS'u :-)

Z której strony? Hehe :) No mam działające łaty imq na 2.6.27 i 2.6.28 ale nie do końca, wszystko ładnie pięknie moduły się ładują, przekierowuje ruch na imq, zakładam kolejki - serwer działa, problem pojawia się w momencie:

rmmod imq

występuje błąd:

unregister_netdevice...

jak nie usuwam modułu wszystko działa ok.

moze glupie pytanie - ale po co na routerze ma byc usuwany w trakcie pracy tak istotny dla jego podstawowej funkcjonalnosci modul ...

jak co to podaj pelen komunikat tego bledu, bo moze on wynikac z zajetosci jakiegos urzadzenia imq

siarka2107 napisał(-a):

bercik wychodzę również z takiego samego założenia i nie usuwam tego modułu, no ale jakby na to nie patrzeć jest to w jakimś stopniu ułomność

jezeli to z powodu samego modulu to jest to ulomnosc (nie pierwsza i nie ostatnia -np. moduly od portu rownoleglego (parport) po wyladowaniu zostawiaja obsluge portu w innym stanie niz przed zaladowaniem) ... ale jezeli nie przeszkadza ona w uzytkowaniu imq to po co zawracac sobie glowe szukaniem czegos innego (chyba ze naprawde nie ma sie co robic :-) )

Czyli nie będzie działać coś takiego:
Na klasie głównej wyłapuje podsieć

tc filter add dev eth1 parent 1:0 protocol ip prio 4 u32 match ip dst 10.0.0.0/24 flowid 1:10

a nastepnie na tej podklasie (1:10) zakladam filtr i kieruje ruch dla danego IP w odpowiednia podklase pochodną od 1:10?

zapodalem tego patcha dla 2.6.28, serwer po uruchomieniu pochodzil jakies moze 5 min i zwis zero sladu w logach na razie odpscilem 28 poczekam moze cos ktos wynajdzie dobrze dzialajacego.
Na 2.6.27.7 kernelu tez mam problem serwer chodzi dluzej jakies dzien dwa i tez dostaje zwisa albo sie restartuje. w logach tez nic, juz sam nie wiem czy to wina kernela czy moze sprzetu, ogolnie jajca mi sie zaczely dziac juz na 2.6.25 po tym jak zapodalem late na L7.

A posiadasz moze patch esfq dla 2.6.26?

dziekuje ci bardzo :)

Coś z htb jest nie tak, ile ludzi/jaki ruch przewala twój router? Może spróbuj moich paczek? Jak masz ustawiony zegar w kernelu? Z tego co czytam na liście mailingowej linux-netdev to developerzy polecają:
- wyłączenie za pomocą ethtool tso i gso na kartach sieciowych,
- zegar ustawić na 1000, mode serwer,
- włączenie high_res,
w/w parametry poprawiają dokładność podziału pasma, temat mówi że htb działa źle a hfsc dobrze, jednak jeśli dobrze się wczytasz wychodzi na to, że i w jednym i w drugim jest coś nie tak, dlatego sugerują używać najnowszych kerneli, gdzie kilka poprawek do htb i estimatora zostało wprowadzonych a i api bardzo się zmienia, w 2.6.29 znowu kilka zmian zostało wprowadzonych, a z tego co wyczytałem to i dla 2.6.30 przygotowane już są następne poprawki, jest tam jeden polak co stara się to wyprowadzić na prostą Jarek Poplawski.
Przy ustawieniu tych parametrów niektórzy zgłaszają również błędy.
Niekiedy lepiej jest nie gonić za najnowszymi kernelami, a pozostać przy starszym stabilnym sofcie, mi najlepiej chodził kernel 2.6.23.x z iptables 1.4.0 i iproute 2.6.23 lub kernel 2.6.24.x z tymi samymi iptablesami i iproute 2.6.25. Teraz pojawia się pytanie czy pozostać przy starych kernelach z wygodnym imq czy stosować najnowsze jednak bez imq, a przerzucić się na troche mniej wygodne i mniej funkcjonalne ifb?

Cześć.

Testowałem chwilę ifb na maszynie wirtualnej i udało się ruch przerzucić w odpowiednie klasy.
Tu gość pisze, że działa jak należyifb+htb

Dla jakiej liczby userów testowaliście ifb i wynik był negatywny?

Zakładam, że w maszynie pracującej jako router są dwie karty: eth0 - LAN, eth1 - WAN. DL dla użytkowników można zlimitować na interfejsie fizycznym, w podanym przeze mnie przykładzie będzie to eth0. Ruch od użytkowników kierujemy na ifb i tu limitujemy im UL. Ruch trafiający na ifb ma źródłowe IP usera.
Czyżby teoria odbiegała od praktyki? :|

Nim przyszło IMQ DL usera limitowany był na interfejsie od strony LAN, a UL usera na interfejsie od strony WAN.

Biorąc na tapetę IFB: ruch przychodzący na interfejs LAN po "src ip" to UL userów - wrzucasz na ifb i kolejkujesz. DL userow limitujesz na fizycznym interfejsie LANu. Dla serwera analogicznie: to co wychodzi z serwera limitujesz na interfejsie WAN a to co przychodzi na interfejs WAN przerzucasz na kolejny IFB i kolejkujesz.

Czy to naprawdę jest niewykonalne z IFB, bo jakoś mi się nie che w to wierzyć.

siarka2107 napisał(-a):

tutaj masz przykład uzycia ifb

siarka2107, rozumiem że to zwrot w stronę urug'a czy też może i moją?