* Re: [LARTC] HTB Rate and Prio
2005-07-08 14:05 [LARTC] HTB Rate and Prio Gael Mauleon
@ 2005-07-08 14:58 ` Jody Shumaker
2005-07-08 16:05 ` Gael Mauleon
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Jody Shumaker @ 2005-07-08 14:58 UTC (permalink / raw)
To: lartc
[-- Attachment #1: Type: text/plain, Size: 5384 bytes --]
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
>
>
>
[-- Attachment #2: Type: text/plain, Size: 143 bytes --]
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 6+ messages in thread* RE: [LARTC] HTB Rate and Prio
2005-07-08 14:05 [LARTC] HTB Rate and Prio Gael Mauleon
2005-07-08 14:58 ` Jody Shumaker
@ 2005-07-08 16:05 ` Gael Mauleon
2005-07-08 19:11 ` Edgar
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: Gael Mauleon @ 2005-07-08 16:05 UTC (permalink / raw)
To: 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
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [LARTC] HTB Rate and Prio
2005-07-08 14:05 [LARTC] HTB Rate and Prio Gael Mauleon
2005-07-08 14:58 ` Jody Shumaker
2005-07-08 16:05 ` Gael Mauleon
@ 2005-07-08 19:11 ` Edgar
2005-07-08 19:23 ` Kirk Reiser
2005-07-08 22:58 ` Francisco Pereira
4 siblings, 0 replies; 6+ messages in thread
From: Edgar @ 2005-07-08 19:11 UTC (permalink / raw)
To: lartc
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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [LARTC] HTB Rate and Prio
2005-07-08 14:05 [LARTC] HTB Rate and Prio Gael Mauleon
` (2 preceding siblings ...)
2005-07-08 19:11 ` Edgar
@ 2005-07-08 19:23 ` Kirk Reiser
2005-07-08 22:58 ` Francisco Pereira
4 siblings, 0 replies; 6+ messages in thread
From: Kirk Reiser @ 2005-07-08 19:23 UTC (permalink / raw)
To: 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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [LARTC] HTB Rate and Prio
2005-07-08 14:05 [LARTC] HTB Rate and Prio Gael Mauleon
` (3 preceding siblings ...)
2005-07-08 19:23 ` Kirk Reiser
@ 2005-07-08 22:58 ` Francisco Pereira
4 siblings, 0 replies; 6+ messages in thread
From: Francisco Pereira @ 2005-07-08 22:58 UTC (permalink / raw)
To: lartc
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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
^ permalink raw reply [flat|nested] 6+ messages in thread