HTB+IMQ+KER.2.6.17 Niestabilny transfer

redeeps - 16-02-2007 18:19
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?
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 - 13-04-2007 21:12
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:

/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):

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 - 14-04-2007 19:44
zainteresuj sie hfsc. gotowe skrypty sa na www.inet.one.pl ja je mocno przerobilem (w sumie to od nowa napisalem) i mi dziala elegancko

Martin - 15-04-2007 23:56
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 - 16-04-2007 10:59
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 - 17-04-2007 23:07
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.
/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 :(.
/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 - 18-04-2007 00:30
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 - 20-04-2007 14:45
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.