On Sunday 09 March 2008 01:42, Radu Oprisan wrote: > Alex wrote: > >> e setat corect mark-ul. regulile de iptables se pun in POSTROUTING si nu > >> pe OUTPUT cu le puneam eu, pentru ca nu se refera la traficul facut de > >> routerul meu, ci la traficul care trece prin el! de aia nu mergea. > > > > am dat cu iftop-ul si desi regulile par a fi ok, treburile nu stau chiar > > asa... > > > > redau regulile puse de mine: > > > > tc class add dev $EXTIF parent 1: classid 1:1 htb rate 1024kbit ceil > > 1024kbit tc class add dev $EXTIF parent 1:1 classid 1:10 htb rate 832kbit > > ceil 1024kbit prio 1 > > tc class add dev $EXTIF parent 1:1 classid 1:11 htb rate 128kbit ceil > > 1024kbit prio 2 > > tc class add dev $EXTIF parent 1:1 classid 1:12 htb rate 64kbit ceil > > 1024kbit prio 3 > > > > traficul http care este asociat clasei 1:10 devine prioritar (fara dubiu, > > verificat de mine). > > > > Acum am insa o nelamurire. Eu doream ca traficul http sa primeasca un min > > de 832k. Un test facut de mine, arata insa ca lucrurile nu stau chiar > > asa. Ce am facut: > > > > - Am dat drumul la un ftp dwl (care doream sa primeasca un min de 64k si > > un max de 1024k - clasa default 1:12). Dupa citeva minute, traficul se > > stabilizeaza in 74-75KB, adica undeva in jur de 600kbps desi banda e > > libera. de ce nu se duce la 1024kbps? > > - dau drumul unui nou dwl, de data aceasta pe http (clasa 1:10). Imediat > > acesta devine prioritar, si ia in jur de 4-500kbps lasind ftp-ul in > > planul doi, cu 3-400k > > - mai dau drumul la inca 2 dwl pe http. traficul total pe eth0 pe http se > > duce in 7-800k. > > - cel de ftp scade pe la 2-300k > > > > Eu ma asteptam ca in acest ultim caz, http-ul sa nu scada sub 832k, iar > > ftp-ul sa zaca la 64kbps... Culmea: rar, dar se intimpla, ca pentru > > scurte intervale de timp, ftp-ul sa sara in fata http-ului ca throughput. > > E normal ce se intimpla? Daca da, de ce, daca nu de ce? > > > > Alx > > Pe ce perioade de timp ai facut tu testele astea?
Se intimpla si dupa 10-15 min de la momentul initial (cind http-ul a "luat fata" ftp-ului). Asta m-a surprins! Pe scurt, eu pe http i-am dat sa traga la greu (dwl 3 imagini iso pe 3 conexiuni diferite), asta dupa ce inainte, aveam pornita deja o conexiune ftp cu un singur dwl. Banda este libera, deci normal, ftp-ul ar trebui sa se duca pina in 1024k (cind e singur pe teava) dar traficul se stabilizeaza pe la 600-700k!!! De ce? Apoi, cind pornesc si trafic http, acesta devine prioritar, dar time to time, pentru scurte intervale de timp (2-3sec), vad cum throughput-ul ftp-ului trece ca valoare peste throughput-ul http-ului (adica in loc ca ftp-ul sa se stabilizeze la valoarea de 64k si sa ramina acolo, acesta ajunge si la 4-500k, in timp ce traficul de http coboara sub 832k)!!! E normal? Atentie: pe eth0, providerul imi aloca mai multa banda decit am pus eu in CEIL. Daca elimin regulile de qos, atit http-ul cit si ftp-ul (pe conexiunile deja stabilite) sar de 1.5mbps, deci este exclus sa fie o limitare venita din partea serverelor (http/ftp) cu care fac eu trafic! Cred ca totusi ceva e putred. Gresesc eu undeva? tc qdisc del dev $EXTIF root tc qdisc add dev $EXTIF root handle 1: htb default 12 tc class add dev $EXTIF parent 1: classid 1:1 htb rate 1024kbit ceil 1024kbit #http tc class add dev $EXTIF parent 1:1 classid 1:10 htb rate 832kbit ceil 1024kbit prio 1 iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp --dport 80 -j MARK --set-mark 20 tc filter add dev $EXTIF parent 1: protocol ip handle 20 fw classid 1:10 #mail tc class add dev $EXTIF parent 1:1 classid 1:11 htb rate 128kbit ceil 1024kbit prio 1 iptables -A POSTROUTING -t mangle -o $EXTIF -p tcp --dport 25 -j MARK --set-mark 30 tc filter add dev $EXTIF parent 1: protocol ip handle 30 fw classid 1:11 #other (inclusiv ftp) tc class add dev $EXTIF parent 1:1 classid 1:12 htb rate 64kbit ceil 1024kbit prio 3 Dupa cum se vede mai sus, celor 3 clase, le asigur un minim de: 832+128+64=1024 (banda totala din CEIL pe eth0). Cind am facut testele de mai sus, nu exista trafic de mail, deci ar mai fi aparut un 128k shared, dar asta nu justifica valorile crescute ale throughput-ului ftp (4-500k) si scazute sub 832k ale http-ului. > Stabilizarea traficului in limitele definite dureaza un pic. deja noi discutam de minute aici, cind stabilizarea e facuta de mult. vad asta cu tc -s -d class show dev eth0. http-ul se duce prin 1:10, iar ftp-ul o ia pe 1:12 (default). > Pe scurt, > exista scurte perioade in care traficul ar putea fi mai jos de minima > sau mai mare de maxima, la modificarea de utilizare pe clase. > > Incearca sa pastrezi limita root-ului tau la 90% din banda reala. Ok. Banda REALA pe eth0 e ceva mai mare. sa zicem dublu, desi poate fi si mai mult. eu am pus in shape-ul tc jumatate (1024k), ca sa fiu sigur ca nu ma doare capul. am incercat sa pun si sfq pe cele 3 clase, dar comportamentul e acelasi. /sbin/tc qdisc add dev $EXTIF parent 1:10 handle 100: sfq perturb 10 #/sbin/tc qdisc add dev $EXTIF parent 1:11 handle 110: sfq perturb 10 /sbin/tc qdisc add dev $EXTIF parent 1:12 handle 120: sfq perturb 10 Ar ajuta daca as pune sfq mai mic pe toate cele 3 clase (sa zicem 5) sau daca as pune sfq diferit pentru clasa 1:10? La final, aplic o regula, care ar trebui sa fie de ajuns pentru a nu avea delay-uri si/sau bottleneck-uri pe incomming (drop la ce depaseste 90% din CEIL cu burst de 10% din CEIL) tc qdisc add dev $EXTIF handle ffff: ingress tc filter add dev $EXTIF parent ffff: protocol ip prio 10 u32 match \ ip src 0.0.0.0/0 police rate $[90*$CEIL/100]kbit burst $[10*$CEIL/100]kbit \ drop flowid :1 mi-a mai scapat ceva? Alx _______________________________________________ RLUG mailing list [email protected] http://lists.lug.ro/mailman/listinfo/rlug
