The priority effects the ratio in which extra bandwidth is shared. Something with a better priority doesn't automatically get all the bandwidth it wants before something with a worse priority, they share it on a ratio basis. You might be better off not using prio and instead just having the rate's for the classes set to the ratio you want. When prio isn't set htb uses the rate's as the ratio. Try removing the prio, and lowering the low-priority even further, say 1kbit instead of 50kbit, then when bandwidth is shared, the other classes will have 750:1 or 400:1 splitting of extra bandwidth. This way your LOWPRIO will also have to borrow for nearly all its bandwidth needs. In your example test case, LOWPRIO was using 500kbit, so borrowing 450kbit, and you say the 750kbit class was using only the remaining 1500kbit, borrowing 750kbit. The ratios of shared ammounts definately doesn't seem to fit with the 5:1 priority's ratio, but I'm no expert on how it determines all this. I just recommend not using the prio and try using a lower rate for the LOWPRIO subclass. - Jody On 7/8/05, Gael Mauleon <admin@xxxxxxxxxxxxxxxxx> wrote: > > > > > > Hi, > > > > I wanted to implement some QOS on my Linux Box with HTB, but after some time > spend > > on the configuration and tests, I still don't manage to have some correct > results. Here are the details : > > > > > > > > -ROOT 2000 kbits > > -HIGHPRIO SUBCLASS 50 kbits prio 0 > > -SUBCLASS1 750 kbits prio 1 > > -SERVICE1 250 kbits prio 1 > > -SERVICE2 250 kbits prio 1 > > -SERVICE3 250 kbits prio 1 > > -SUBCLASS2 750 kbits prio 1 > > -SERVICE1 250 kbits prio 1 > > -SERVICE2 250 kbits prio 1 > > -SERVICE3 250 kbits prio 1 > > -SUBCLASS3 400 kbits prio 1 > > -SERVICE1 200 kbits prio 1 > > -SERVICE2 200 kbits prio 1 > > -LOWPRIO SUBCLASS 50 kbits prio 5 > > > > Here is the details of the implementation, I only wrote 1 on the subclass > > Cause they are all on the same template. > > > > > > tc qdisc add dev $QOSIN root handle 1:0 htb default 1000 > > tc class add dev $QOSIN parent 1:0 classid 1:1 htb rate 2000kbit > > > > ### SUBCLASS1 > > tc class add dev $QOSIN parent 1:1 classid 1:10 htb rate 750kbit ceil > 2000kbit prio 1 > > tc class add dev $QOSIN parent 1:10 classid 1:101 htb rate 250kbit ceil > 2000kbit prio 1 > > tc qdisc add dev $QOSIN parent 1:101 handle 101: pfifo limit 10 > > tc class add dev $QOSIN parent 1:10 classid 1:102 htb rate 250kbit ceil > 2000kbit prio 1 > > tc qdisc add dev $QOSIN parent 1:102 handle 102: pfifo limit 10 > > tc class add dev $QOSIN parent 1:10 classid 1:103 htb rate 250kbit ceil > 2000kbit prio 1 > > tc qdisc add dev $QOSIN parent 1:103 handle 103: pfifo limit 10 > > > > tc filter add dev $QOSIN parent 1:0 protocol ip handle $OUTPROD$MAIL fw > flowid 1:101 > > tc filter add dev $QOSIN parent 1:0 protocol ip handle $OUTPROD$HTTP fw > flowid 1:102 > > tc filter add dev $QOSIN parent 1:0 protocol ip handle $OUTPROD$FTP fw > flowid 1:103 > > > > etc… > > > > > > ### HIGH PRIO ### > > tc class add dev $QOSIN parent 1:1 classid 1:50 htb rate 50kbit ceil > 2000kbit prio 0 quantum 1500 > > tc qdisc add dev $QOSIN parent 1:50 handle 50: pfifo limit 10 > > tc filter add dev $QOSIN parent 1:0 protocol ip handle $OUTPROD$HIGHPRIO fw > flowid 1:50 > > tc filter add dev $QOSIN parent 1:0 protocol ip handle $OUTPOSTPROD$HIGHPRIO > fw flowid 1:50 > > tc filter add dev $QOSIN parent 1:0 protocol ip handle $OUTDMZ$HIGHPRIO fw > flowid 1:50 > > > > ### LOW PRIO ### > > tc class add dev $QOSIN parent 1:1 classid 1:60 htb rate 50kbit ceil > 2000kbit prio 5 quantum 1500 > > tc qdisc add dev $QOSIN parent 1:60 handle 60: pfifo limit 10 > > tc filter add dev $QOSIN parent 1:0 protocol ip handle $OUTPROD$LOWPRIO fw > flowid 1:60 > > tc filter add dev $QOSIN parent 1:0 protocol ip handle $OUTPOSTPROD$LOWPRIO > fw flowid 1:60 > > tc filter add dev $QOSIN parent 1:0 protocol ip handle $OUTDMZ$LOWPRIO fw > flowid 1:60 > > > > > > Every traffic seems to go in the class it must go, the stats are good and if > I change any of the ceil rate > > the associated traffic is caped to the right ceil I enter. > > > > Now with this configuration I expected that when one of the SUBCLASS class > or SERVICE want more bandwith than its > > rate, she can borrow it from root and she had it before LOW PRIO and after > HIGH PRIO. > > > > But it don't work at all, for exemple I tried only with 2 flow, I have 500 > Kbits of LOW PRIO traffic that is currently > > going on, then I fire some SERVICE1 traffic from SUBCLASS1 that can > theorically take 2000 kbits, and instead > > of taking it from LOW PRIO, it just take what is left… > > > > I surely miss something… > > > > Thanks for your help and don't hesitate to ask more infos J > > > > Gael. > > > > > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > >
_______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
