HTB, IMQ i j

Konfiguracja serwerów, usług, itp.
redeeps
Posty: 2
Rejestracja: 16 lutego 2007, 18:12

HTB, IMQ i jądro 2.6.17 - niestabilny transfer

Post autor: redeeps »

Witam.
Mam taki problem. Konfiguruje sobie od jakiegoś czasu serwer na Debianie 3.1r4. Skompilowałem jądro i iptables z patchami pod IMQ i LAYER7. Zainstalowałem iproute z dselect'a. Stworzyłem prosty i skromny skrypt dla HTB. Uruchomiłem skrypt podłączyłem sie do ftpa przez lan i zaczynam sobie sciagac pliczek. W HTB ustawione ograniczenie 180kbit. No i wszystko pięknie transfer 22,5KB/s, ale po chwili transfer zjezdza do 10,5KB/s, żeby znowu po chwili podskoczyć do 30KB/s i tak w kółko, a średni transfer jest grubo poniżej wymaganego. Przez http jest tak samo. Czytałem też coś o htbfair.diff ale do tej wersji Kernela chyba nie ma takiego patcha?

Próbowałem różnych konfiguracji kernela i nic to nie daje, żadnych zmian ciągle jest tak samo. Nowszego jądra nie wezme bo nie ma patcha IMQ. Zostaje mi tylko jeszcze sprawdzić starsze:\. Ale może to nie wina jądra?

Kod: Zaznacz cały

IMQ_NET="eth0"
TCIQNC="tc class add dev $IMQ_NET parent"
TCIQNF="tc filter add dev $IMQ_NET parent"
TCIQNQ="tc qdisc add dev $IMQ_NET parent"

ip link set $IMQ_NET up
tc qdisc del dev $IMQ_NET root >/dev/null 2>&1
tc qdisc add dev $IMQ_NET root handle 2:0 htb default 4 r2q 1
$TCIQNC 2:0 classid 2:1 htb rate ${MAX_UP}kbit ceil ${MAX_UP}kbit quantum 10000
$TCIQNC 2:1 classid 2:2 htb rate ${COMP_MAX_UP}kbit ceil ${COMP_MAX_UP}kbit
$TCIQNC 2:1 classid 2:3 htb rate ${VOIP}kbit ceil ${VOIP}kbit
for i in `seq 1 ${#IP[*]}`; do
        $TCIQNC 2:2 classid 2:$((10 + $i)) htb rate ${UPMIN[$i]}kbit ceil ${UPMAX[$i]}kbit
done
$TCIQNC 2:2 classid 2:4 htb rate 10kbit ceil 50kbit
for i in `seq 1 ${#IP[*]}`; do
    $TCIQNF 2:0 protocol ip prio ${PRIO[$i]} u32 match ip src ${IP[$i]} flowid 2:$(( 10 + $i ))
done
for i in `seq 1 ${#IP[*]}`; do
    $TCIQNQ 2:$((10 + $i)) handle $((10+$i)):0 sfq perturb 10
done
$TCIQNQ 2:4 handle 4:0 sfq perturb 10
IP,PRIO,UPMIN,UPMAX są wczytywane z pliku.
Docelowo IMQ_NET=imq0 ale w celu sprawdzenia czy to przypadkiem nie przez imq zmienilem na eth0.

Kernel 2.6.17.14
Iptables 1.3.7
iptables-1.3.0-imq1.diff
linux-2.6.17-imq1.diff
Sprzęt: P3 500mhz 128mb, eth0 std. realtek 100mbit

Czy ktoś miał podobny problem albo wie o co może chodzić? Nie chce zmieniać HTB na innego kolejarza.
Z góry dzieki!
Martin
Posty: 8
Rejestracja: 18 marca 2007, 09:13

Mam podobny problem

Post autor: Martin »

Dołączam się do pytania bo mam podobny problem. Wszystkie potrzebne moduły mam do zrobienia HTB i narzędzia również. Jądro 2.6.18-4 ale na 2.6.20 również miałem to samo.

Takie same konfiguracje używałem na innych maszynach np z jądrem 2.6.15 i wszystko działało.
Czy jest możliwe, że wynika to z 64bitowej platformy (intel core 2 duo) albo kart sieciowych 1 Gbitowych?

Regułki które tworzą ograniczenie:

Kod: Zaznacz cały

/sbin/tc class add dev eth1 parent 1:2 classid 1:62 htb rate 300Kbit burst 15Kb cburst 15Kb
/sbin/tc qdisc add dev eth1 parent 1:62 handle 62 sfq perturb 10
/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.1.59 classid 1:62
A takie sytuacje mają miejsce:
tc -s -d class show dev eth1 (bo głównie chodzi o jeden interfejs):

Kod: Zaznacz cały

class htb 1:62 parent 1:2 leaf 62: prio 0 quantum 18750 rate 300000bit ceil 300000bit burst 15Kb/8 mpu 0b ov
 Sent 133919082 bytes 68456 pkt (dropped 0, overlimits 0 requeues 0)
 rate 407544bit 23pps backlog 0b 6p requeues 0
 lended: 68450 borrowed: 0 giants: 45232
 tokens: -444687 ctokens: -444687
U mnie wygląda to bardziej tak, że pasmo nie jest przycinane precyzyjnie i często przekracza zadaną wartość.

Pozdrawiam
ukasz83
Posty: 10
Rejestracja: 14 kwietnia 2007, 19:42

Post autor: ukasz83 »

zainteresuj sie hfsc. gotowe skrypty sa na http://www.inet.one.pl ja je mocno przerobilem (w sumie to od nowa napisalem) i mi dziala elegancko
Martin
Posty: 8
Rejestracja: 18 marca 2007, 09:13

hfsc...:/

Post autor: Martin »

Dzięki za podpowiedź. Przyjrzałem się hfsc i skryptom o których mówiłeś. Jednak dla mnie ma to jedną DU¯¡ wadę. Podczas próby uruchomienia ciągle dostaje błąd HFSC: Illegal "ls" i z tego co się dowiedziałem na forum i.NET to występuje gdy się przekroczy pasmo swojego łącza w przydziałach prędkości. Próbowałem różnych ustawień i lipa.
Będę dalej kombinował żeby uruchomić moje stare poczciwe HTB

Pozdrawiam
ukasz83
Posty: 10
Rejestracja: 14 kwietnia 2007, 19:42

Post autor: ukasz83 »

moim zdanim lepsze jest hfsc. masz juz gotowe skrypty. suma gwarantowanej predkosci nie moze przekraczac maksymalnego uploadu / downloadu to jest zasada ktora tez sie tyczy htb
Martin
Posty: 8
Rejestracja: 18 marca 2007, 09:13

Post autor: Martin »

Wiem już o co chodzi. Te przekroczenia transferów wynikają z proxy. Na forum i.net jest o tym mowa i załatwiają to poprzez wrzucenie ruchu z proxy do jednej z kolejek. Ja wolałbym wrzucić każdemu użytkownikowi osobno. Dziwi mnie to że ustawienia które podałem tzn.

Kod: Zaznacz cały

/sbin/tc class add dev eth1 parent 1:2 classid 1:62 htb rate 300Kbit burst 15Kb cburst 15Kb
/sbin/tc qdisc add dev eth1 parent 1:62 handle 62 sfq perturb 10
/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 192.168.1.59 classid 1:62
nie działają mi obecnie chociaż działały na poprzednim serwerze i na innym obecnie uruchomionym też.
Nawet gdy określam filtry w postaci jak poniżej to też nie działa :( .

Kod: Zaznacz cały

 /sbin/tc filter add dev eth1 parent 1:0 prio 100 u32 match ip sport 80 0xffff match ip dst 192.168.2.92 classid 1:2092
lub
 /sbin/tc filter replace dev eth1 parent 1:0 prio 100 u32 match ip src 192.168.2.1 match ip sport 80 0xffff match ip dst 192.168.2.92 classid 1:2092
Dlaczego squid obchodzi HTB? Delay pools na squidzie wprawdzie działają ale zależy mi na tym aby każdemu użytkownikowi przypisać konkretne pasmo niezależnie co pobiera.
ukasz83
Posty: 10
Rejestracja: 14 kwietnia 2007, 19:42

Post autor: ukasz83 »

przekieruj ruch do imq. ten z interfejsu wan i lan. zrobisz kolejki eleganckie
tylko musisz pamietac zebys nie ograniczyl ruchu po lanie tylko ruch od i do proxy z serwera

do proxy jest jeszce patch hit i miss. jesli bedzie hit to znaczy ze jest stronka na proxy. jesli miss to znaczy ze stronka bedzie zbuforowana do proxy.
Martin
Posty: 8
Rejestracja: 18 marca 2007, 09:13

rozwiązałem swój problem

Post autor: Martin »

Do kolejek dodałem MTU na poziomie 16400 i poprawiło sprawę. Brak ograniczenia wynikał z pakietów 'giants' których rozmiar przekraczał wartość MTU ustawioną w kolejkach.
ODPOWIEDZ