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@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
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@premiere-heure.fr> 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@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > > >_______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Thanks for the anwser, I just tried that with a 10 kbits rate and no Priority but it don''t seems to change something in the behavior of the QOS... Well to make it clear here is the full infos (sorry for the flood ) -> class htb 1:101 parent 1:10 leaf 101: prio 0 rate 250000bit ceil 2000Kbit burst 1912b cburst 4Kb Sent 266737 bytes 372 pkts (dropped 0, overlimits 0) rate 48440bit 5pps lended: 265 borrowed: 107 giants: 0 tokens: 87000 ctokens: 23695 class htb 1:202 parent 1:20 leaf 202: prio 0 rate 250000bit ceil 2000Kbit burst 1912b cburst 4Kb Sent 39266 bytes 325 pkts (dropped 0, overlimits 0) rate 3800bit 3pps lended: 325 borrowed: 0 giants: 0 tokens: 87522 ctokens: 23789 class htb 1:1 root rate 2000Kbit ceil 2000Kbit burst 4Kb cburst 4Kb Sent 43212627 bytes 42882 pkts (dropped 0, overlimits 0) rate 1765Kbit 212pps lended: 28370 borrowed: 0 giants: 0 tokens: -17118 ctokens: -17118 class htb 1:10 parent 1:1 rate 750000bit ceil 2000Kbit burst 2536b cburst 4Kb Sent 37117090 bytes 28128 pkts (dropped 0, overlimits 0) rate 1551Kbit 143pps lended: 7561 borrowed: 14583 giants: 0 tokens: -71625 ctokens: -17118 class htb 1:203 parent 1:20 leaf 203: prio 0 rate 250000bit ceil 2000Kbit burst 1912b cburst 4Kb Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 89625 ctokens: 24023 class htb 1:103 parent 1:10 leaf 103: prio 0 rate 250000bit ceil 2000Kbit burst 1912b cburst 4Kb Sent 36716334 bytes 26167 pkts (dropped 0, overlimits 0) rate 1505Kbit 133pps backlog 4p lended: 4126 borrowed: 22037 giants: 0 tokens: -114281 ctokens: -17118 class htb 1:20 parent 1:1 rate 750000bit ceil 2000Kbit burst 2536b cburst 4Kb Sent 39266 bytes 325 pkts (dropped 0, overlimits 0) rate 3800bit 3pps lended: 0 borrowed: 0 giants: 0 tokens: 39016 ctokens: 23789 class htb 1:102 parent 1:10 leaf 102: prio 0 rate 250000bit ceil 2000Kbit burst 1912b cburst 4Kb Sent 138883 bytes 1593 pkts (dropped 0, overlimits 0) rate 3176bit 4pps lended: 1593 borrowed: 0 giants: 0 tokens: 87750 ctokens: 23789 class htb 1:201 parent 1:20 leaf 201: prio 0 rate 250000bit ceil 2000Kbit burst 1912b cburst 4Kb Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 89625 ctokens: 24023 class htb 1:40 parent 1:1 rate 400000bit ceil 2000Kbit burst 2099b cburst 4Kb Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 61523 ctokens: 24023 class htb 1:50 parent 1:1 leaf 50: prio 0 rate 90000bit ceil 2000Kbit burst 1711b cburst 4Kb Sent 3516 bytes 55 pkts (dropped 0, overlimits 0) rate 144bit lended: 55 borrowed: 0 giants: 0 tokens: 214583 ctokens: 23648 class htb 1:402 parent 1:40 leaf 402: prio 0 rate 200000bit ceil 2000Kbit burst 1849b cburst 4Kb Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 108398 ctokens: 24023 class htb 1:60 parent 1:1 leaf 60: prio 0 rate 10000bit ceil 2000Kbit burst 1611b cburst 4Kb Sent 6052835 bytes 14376 pkts (dropped 0, overlimits 0) rate 210184bit 65pps backlog 2p lended: 587 borrowed: 13787 giants: 0 tokens: -2173243 ctokens: 8339 class htb 1:403 parent 1:40 leaf 403: prio 0 rate 200000bit ceil 2000Kbit burst 1849b cburst 4Kb Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 tokens: 108398 ctokens: 24023 ############################## qdisc htb 1: dev imq1 r2q 10 default 1000 direct_packets_stat 11 Sent 46576898 bytes 49981 pkts (dropped 0, overlimits 33216) qdisc sfq 101: dev imq1 parent 1:101 limit 128p quantum 1500b perturb 10sec Sent 295953 bytes 742 pkts (dropped 0, overlimits 0) qdisc sfq 102: dev imq1 parent 1:102 limit 128p quantum 1500b perturb 10sec Sent 163583 bytes 1984 pkts (dropped 0, overlimits 0) qdisc sfq 103: dev imq1 parent 1:103 limit 128p quantum 1500b perturb 10sec Sent 38352553 bytes 27341 pkts (dropped 0, overlimits 0) qdisc sfq 201: dev imq1 parent 1:201 limit 128p quantum 1500b perturb 10sec Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc sfq 202: dev imq1 parent 1:202 limit 128p quantum 1500b perturb 10sec Sent 51981 bytes 415 pkts (dropped 0, overlimits 0) qdisc sfq 203: dev imq1 parent 1:203 limit 128p quantum 1500b perturb 10sec Sent 47507 bytes 904 pkts (dropped 0, overlimits 0) qdisc sfq 403: dev imq1 parent 1:403 limit 128p quantum 1500b perturb 10sec Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc sfq 402: dev imq1 parent 1:402 limit 128p quantum 1500b perturb 10sec Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc sfq 50: dev imq1 parent 1:50 limit 128p quantum 1500b perturb 10sec Sent 4089 bytes 64 pkts (dropped 0, overlimits 0) qdisc sfq 60: dev imq1 parent 1:60 limit 128p quantum 1500b perturb 10sec Sent 7659072 bytes 18520 pkts (dropped 0, overlimits 0) ############################## I changed pfifo queue to sfq ones, it seems i have better results with them, And clear the priorities but none changed... So the interesting things here are the 1:60 class and the 1:103 one. 1:60 is the low prio stuffs so she add only 10kbits rate and the 1:103 one have 250kbits rate and is a child of 1:10 which have 750kbits rate. The 1:103 is sending to max so in theory, regarding the rates she would take almost all the bandwith but 1:60 just don''t move, she was at 210kbits before 1:103 start to send and is still at 210kbits after...and she don''t even drop 1 packet.... This is with or without priorities (was at 5 on 1:60 and 1 on 1:103 before) The second things I''m not sure is the overlimits of the main qdisc, what does it mean ?? It''s just like the whole qos system don''t even work, but i repeat if i set for exemple the ceil of 1:103 to 50kbits or the ceil of 1:60 to 50 kbits they are limited to those rate and drop counter goes up... Packets are there but they don''t seem to be shaped just caped if I tune the ceil of class... In short.. HEELLLLP :o)p> -----Message d''origine----- > De : lartc-bounces@mailman.ds9a.nl [mailto:lartc-bounces@mailman.ds9a.nl] > De la part de Jody Shumaker > Envoyé : vendredi 8 juillet 2005 16:59 > À : lartc@mailman.ds9a.nl > Objet : Re: [LARTC] HTB Rate and Prio > > 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 >
Hello, I''m having kind of the same problem with bittorrent, I''m about to lower the rates to see what happens, but I''m also suffering from that, the p2p class should be lowprio, and everything else normal and high, but when bittorrent is up (and it''s got only 10kb out of 22kb available) I can''t do anything else, I''m gonna keep a track on your post and provide you the help I find and get by other in this list, and see if it works for both. EDGAR MERINO On Friday 08 July 2005 11:05, Gael Mauleon wrote:> Thanks for the anwser, I just tried that with a 10 kbits rate and no > Priority but it don''t seems to change something in the behavior of the > QOS... > > Well to make it clear here is the full infos (sorry for the flood ) -> > > class htb 1:101 parent 1:10 leaf 101: prio 0 rate 250000bit ceil 2000Kbit > burst 1912b cburst 4Kb > Sent 266737 bytes 372 pkts (dropped 0, overlimits 0) > rate 48440bit 5pps > lended: 265 borrowed: 107 giants: 0 > tokens: 87000 ctokens: 23695 > > class htb 1:202 parent 1:20 leaf 202: prio 0 rate 250000bit ceil 2000Kbit > burst 1912b cburst 4Kb > Sent 39266 bytes 325 pkts (dropped 0, overlimits 0) > rate 3800bit 3pps > lended: 325 borrowed: 0 giants: 0 > tokens: 87522 ctokens: 23789 > > class htb 1:1 root rate 2000Kbit ceil 2000Kbit burst 4Kb cburst 4Kb > Sent 43212627 bytes 42882 pkts (dropped 0, overlimits 0) > rate 1765Kbit 212pps > lended: 28370 borrowed: 0 giants: 0 > tokens: -17118 ctokens: -17118 > > class htb 1:10 parent 1:1 rate 750000bit ceil 2000Kbit burst 2536b cburst > 4Kb > Sent 37117090 bytes 28128 pkts (dropped 0, overlimits 0) > rate 1551Kbit 143pps > lended: 7561 borrowed: 14583 giants: 0 > tokens: -71625 ctokens: -17118 > > class htb 1:203 parent 1:20 leaf 203: prio 0 rate 250000bit ceil 2000Kbit > burst 1912b cburst 4Kb > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > lended: 0 borrowed: 0 giants: 0 > tokens: 89625 ctokens: 24023 > > class htb 1:103 parent 1:10 leaf 103: prio 0 rate 250000bit ceil 2000Kbit > burst 1912b cburst 4Kb > Sent 36716334 bytes 26167 pkts (dropped 0, overlimits 0) > rate 1505Kbit 133pps backlog 4p > lended: 4126 borrowed: 22037 giants: 0 > tokens: -114281 ctokens: -17118 > > class htb 1:20 parent 1:1 rate 750000bit ceil 2000Kbit burst 2536b cburst > 4Kb > Sent 39266 bytes 325 pkts (dropped 0, overlimits 0) > rate 3800bit 3pps > lended: 0 borrowed: 0 giants: 0 > tokens: 39016 ctokens: 23789 > > class htb 1:102 parent 1:10 leaf 102: prio 0 rate 250000bit ceil 2000Kbit > burst 1912b cburst 4Kb > Sent 138883 bytes 1593 pkts (dropped 0, overlimits 0) > rate 3176bit 4pps > lended: 1593 borrowed: 0 giants: 0 > tokens: 87750 ctokens: 23789 > > class htb 1:201 parent 1:20 leaf 201: prio 0 rate 250000bit ceil 2000Kbit > burst 1912b cburst 4Kb > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > lended: 0 borrowed: 0 giants: 0 > tokens: 89625 ctokens: 24023 > > class htb 1:40 parent 1:1 rate 400000bit ceil 2000Kbit burst 2099b cburst > 4Kb > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > lended: 0 borrowed: 0 giants: 0 > tokens: 61523 ctokens: 24023 > > class htb 1:50 parent 1:1 leaf 50: prio 0 rate 90000bit ceil 2000Kbit burst > 1711b cburst 4Kb > Sent 3516 bytes 55 pkts (dropped 0, overlimits 0) > rate 144bit > lended: 55 borrowed: 0 giants: 0 > tokens: 214583 ctokens: 23648 > > class htb 1:402 parent 1:40 leaf 402: prio 0 rate 200000bit ceil 2000Kbit > burst 1849b cburst 4Kb > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > lended: 0 borrowed: 0 giants: 0 > tokens: 108398 ctokens: 24023 > > class htb 1:60 parent 1:1 leaf 60: prio 0 rate 10000bit ceil 2000Kbit burst > 1611b cburst 4Kb > Sent 6052835 bytes 14376 pkts (dropped 0, overlimits 0) > rate 210184bit 65pps backlog 2p > lended: 587 borrowed: 13787 giants: 0 > tokens: -2173243 ctokens: 8339 > > class htb 1:403 parent 1:40 leaf 403: prio 0 rate 200000bit ceil 2000Kbit > burst 1849b cburst 4Kb > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > lended: 0 borrowed: 0 giants: 0 > tokens: 108398 ctokens: 24023 > > > ############################## > > qdisc htb 1: dev imq1 r2q 10 default 1000 direct_packets_stat 11 > Sent 46576898 bytes 49981 pkts (dropped 0, overlimits 33216) > qdisc sfq 101: dev imq1 parent 1:101 limit 128p quantum 1500b perturb 10sec > Sent 295953 bytes 742 pkts (dropped 0, overlimits 0) > qdisc sfq 102: dev imq1 parent 1:102 limit 128p quantum 1500b perturb 10sec > Sent 163583 bytes 1984 pkts (dropped 0, overlimits 0) > qdisc sfq 103: dev imq1 parent 1:103 limit 128p quantum 1500b perturb 10sec > Sent 38352553 bytes 27341 pkts (dropped 0, overlimits 0) > qdisc sfq 201: dev imq1 parent 1:201 limit 128p quantum 1500b perturb 10sec > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > qdisc sfq 202: dev imq1 parent 1:202 limit 128p quantum 1500b perturb 10sec > Sent 51981 bytes 415 pkts (dropped 0, overlimits 0) > qdisc sfq 203: dev imq1 parent 1:203 limit 128p quantum 1500b perturb 10sec > Sent 47507 bytes 904 pkts (dropped 0, overlimits 0) > qdisc sfq 403: dev imq1 parent 1:403 limit 128p quantum 1500b perturb 10sec > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > qdisc sfq 402: dev imq1 parent 1:402 limit 128p quantum 1500b perturb 10sec > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > qdisc sfq 50: dev imq1 parent 1:50 limit 128p quantum 1500b perturb 10sec > Sent 4089 bytes 64 pkts (dropped 0, overlimits 0) > qdisc sfq 60: dev imq1 parent 1:60 limit 128p quantum 1500b perturb 10sec > Sent 7659072 bytes 18520 pkts (dropped 0, overlimits 0) > > > > ############################## > > > I changed pfifo queue to sfq ones, it seems i have better results with > them, And clear the priorities but none changed... > > So the interesting things here are the 1:60 class and the 1:103 one. > 1:60 is the low prio stuffs so she add only 10kbits rate and the > 1:103 one have 250kbits rate and is a child of 1:10 which have 750kbits > rate. > > The 1:103 is sending to max so in theory, regarding the rates she would > take almost all the bandwith but 1:60 just don''t move, she was at 210kbits > before 1:103 start to send and is still at 210kbits after...and she don''t > even drop 1 packet.... > This is with or without priorities (was at 5 on 1:60 and 1 on 1:103 before) > > The second things I''m not sure is the overlimits of the main qdisc, what > does it mean ?? > > It''s just like the whole qos system don''t even work, but i repeat if i set > for exemple the ceil of 1:103 to 50kbits or the ceil of 1:60 to 50 kbits > they are limited to those rate and drop counter goes up... > > Packets are there but they don''t seem to be shaped just caped if I tune the > ceil of class... > > In short.. HEELLLLP :o)p > > > -----Message d''origine----- > > De : lartc-bounces@mailman.ds9a.nl [mailto:lartc-bounces@mailman.ds9a.nl] > > De la part de Jody Shumaker > > Envoyé : vendredi 8 juillet 2005 16:59 > > À : lartc@mailman.ds9a.nl > > Objet : Re: [LARTC] HTB Rate and Prio > > > > 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 > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
I don''t quite understand this problem with bit torrent. When I start bittorrent with it''s max_upload_rate to a value less than my total up link bandwidth it doesn''t get in the way of anything at all as far as I can tell. Kirk -- Kirk Reiser The Computer Braille Facility e-mail: kirk@braille.uwo.ca University of Western Ontario phone: (519) 661-3061
Kirk Reiser wrote:> I don''t quite understand this problem with bit torrent. When I start > bittorrent with it''s max_upload_rate to a value less than my total up > link bandwidth it doesn''t get in the way of anything at all as far as > I can tell. > > Kirk >Not all network administrators have your luck. :-) The problem is when you can''t control the workstations, and the users can use this kind of network-unfriendly software (that try to "steal" the other software or users bandwidth) I believe that it is important in a network the user''s perception of "the network speed", basically in all the interactive traffic. I dont know the existence of a framework to model the user perception, which will allow to take measures of this kind of parameters. I''m not talking about delays, jitter, etc, but about the user''s perception, and how the user''s perception can be enhanced. Regards, Francisco.