* [LARTC] [LONG] Weights not working
@ 2003-07-26 4:32 Raj Mathur
2003-07-26 4:59 ` Rio Martin.
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: Raj Mathur @ 2003-07-26 4:32 UTC (permalink / raw)
To: lartc
Hi,
The Description
---------------
Am making a package for a VSAT ISP. Running Red Hat 8.0 with the
updated kernel (2.4.20) and patched for HTB on the bandwidth
management system (BMS). BMS has two ethernet interfaces: eth1 at
192.168.0.1/24 going to the LAN with PCs and eth0 at 10.9.25.34/28
going to the VSAT uplink.
Kernel HTB version: HTB init, kernel part version 3.10
Using the htb.init script v0.8.4
Throttling total outgoing VSAT bandwidth on eth0 at 64 Kbps.
Throttling total incoming VSAT bandwidth on eth1 at 256 Kbps.
Throttling total incoming/outgoing bandwidth for sets of PCs on the
LAN on eth1/eth0 respectively using netfilter marks.
PC pools on the LAN (IP, Min/Max download bandwidth allocated):
(a) 192.168.0.64/31 (32/128)
(b) 192.160.0.2/32 (128/256)
(c) 192.168.0.3 (32/128)
The Problem
-----------
Throttling is working fine in both directions. However, when the link
is choked the PCs do not get bandwidth proportional to their RATEs or
CEILs. So if all the PCs start downloading simultaneously, each pool
gets ~85 Kbps, instead of pools (a) and (c) getting 64 Kbps each and
(b) getting 128 Kbps.
Enclosing the files from /etc/sysconfig/htb and the htb compile
output. Thanks in advance for any help.
Regards,
-- Raju
--
Raj Mathur raju@kandalaya.org http://kandalaya.org/
GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F
It is the mind that moves
*** eth0 ***
DEFAULT0
*** eth0-0003,upload ***
RATEdKbps
PRIO=5
*** eth0-0003:0003.192.168.0.64.upload ***
RATE=8Kbit
CEIL Kbit
PRIO=5
LEAF=sfq
MARK=3
*** eth0-0003:0004.192.168.0.2.upload ***
RATE2Kbit
CEILdKbit
PRIO=5
LEAF=sfq
MARK=1
*** eth0-0003:0005.192.168.0.3.upload ***
RATE=8Kbit
CEIL Kbit
PRIO=5
LEAF=sfq
MARK=2
*** eth1 ***
DEFAULT0
*** eth1-0002.download ***
RATE%6Kbps
PRIO=5
*** eth1-0002:0003.192.168.0.64.download ***
RATE2Kbit
CEIL\x128Kbit
PRIO=5
LEAF=sfq
MARKe539
*** eth1-0002:0004.192.168.0.2.download ***
RATE\x128Kbit
CEIL%6Kbit
PRIO=5
LEAF=sfq
MARKe537
*** eth1-0002:0005.192.168.0.3.download ***
RATE2Kbit
CEIL\x128Kbit
PRIO=5
LEAF=sfq
MARKe538
*** htb compile ***
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1 htb default 30
tc qdisc del dev eth1 root
tc qdisc add dev eth1 root handle 1 htb default 30
tc class add dev eth0 parent 1: classid 1:0003 htb rate 64Kbps prio 5
tc class add dev eth0 parent 1:0003 classid 1:0003 htb rate 8Kbit ceil 20Kbit prio 5
tc qdisc add dev eth0 parent 1:0003 handle 0003 sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 200 handle 3 fw classid 1:0003
tc class add dev eth0 parent 1:0003 classid 1:0004 htb rate 32Kbit ceil 64Kbit prio 5
tc qdisc add dev eth0 parent 1:0004 handle 0004 sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 200 handle 1 fw classid 1:0004
tc class add dev eth0 parent 1:0003 classid 1:0005 htb rate 8Kbit ceil 20Kbit prio 5
tc qdisc add dev eth0 parent 1:0005 handle 0005 sfq perturb 10
tc filter add dev eth0 parent 1:0 protocol ip prio 200 handle 2 fw classid 1:0005
tc class add dev eth1 parent 1: classid 1:0002 htb rate 256Kbps prio 5
tc class add dev eth1 parent 1:0002 classid 1:0003 htb rate 32Kbit ceil 128Kbit prio 5
tc qdisc add dev eth1 parent 1:0003 handle 0003 sfq perturb 10
tc filter add dev eth1 parent 1:0 protocol ip prio 200 handle 65539 fw classid 1:0003
tc class add dev eth1 parent 1:0002 classid 1:0004 htb rate 128Kbit ceil 256Kbit prio 5
tc qdisc add dev eth1 parent 1:0004 handle 0004 sfq perturb 10
tc filter add dev eth1 parent 1:0 protocol ip prio 200 handle 65537 fw classid 1:0004
tc class add dev eth1 parent 1:0002 classid 1:0005 htb rate 32Kbit ceil 128Kbit prio 5
tc qdisc add dev eth1 parent 1:0005 handle 0005 sfq perturb 10
tc filter add dev eth1 parent 1:0 protocol ip prio 200 handle 65538 fw classid 1:0005
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [LARTC] [LONG] Weights not working
2003-07-26 4:32 [LARTC] [LONG] Weights not working Raj Mathur
@ 2003-07-26 4:59 ` Rio Martin.
2003-07-26 6:21 ` Raj Mathur
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Rio Martin. @ 2003-07-26 4:59 UTC (permalink / raw)
To: lartc
On Saturday 26 July 2003 11:20, Raj Mathur wrote:
> Hi,
> The Description
> ---------------
> Am making a package for a VSAT ISP. Running Red Hat 8.0 with the
> updated kernel (2.4.20) and patched for HTB on the bandwidth
> management system (BMS). BMS has two ethernet interfaces: eth1 at
... [x]
> The Problem
> -----------
> Throttling is working fine in both directions. However, when the link
> is choked the PCs do not get bandwidth proportional to their RATEs or
> CEILs. So if all the PCs start downloading simultaneously, each pool
> gets ~85 Kbps, instead of pools (a) and (c) getting 64 Kbps each and
> (b) getting 128 Kbps.
It will be getting worse if your hosts start to open Kazaa or Download
Accelerator Pro brutally (let say 10 - 20 DAP, Kazaa, FlashGet)
As i ve seen in your script, you didnt play the Quantum value.. This is
exactly the same just like i did my HTB working for the first time..
Set the Quantum value to suits your bandwidth manager..
Regards,
Rio Martin.
--
Look, we play the Star Spangled Banner before every game. You want us
to pay income taxes, too?
-- Bill Veeck, Chicago White Sox
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [LARTC] [LONG] Weights not working
2003-07-26 4:32 [LARTC] [LONG] Weights not working Raj Mathur
2003-07-26 4:59 ` Rio Martin.
@ 2003-07-26 6:21 ` Raj Mathur
2003-07-29 5:22 ` Rio Martin.
2003-07-29 7:42 ` Stef Coene
3 siblings, 0 replies; 5+ messages in thread
From: Raj Mathur @ 2003-07-26 6:21 UTC (permalink / raw)
To: lartc
Hi Rio,
>>>>> "Rio" = Rio Martin <rio@martin.mu> writes:
>> The Problem
>> -----------
>> Throttling is working fine in both directions. However, when
>> the link is choked the PCs do not get bandwidth proportional to
>> their RATEs or CEILs. So if all the PCs start downloading
>> simultaneously, each pool gets ~85 Kbps, instead of pools (a)
>> and (c) getting 64 Kbps each and (b) getting 128 Kbps.
Rio> It will be getting worse if your hosts start to open Kazaa or
Rio> Download Accelerator Pro brutally (let say 10 - 20 DAP,
Rio> Kazaa, FlashGet)
Rio> As i ve seen in your script, you didnt play the Quantum
Rio> value.. This is exactly the same just like i did my HTB
Rio> working for the first time.. Set the Quantum value to suits
Rio> your bandwidth manager..
Hmm, so if I understand you correctly you're saying that the QUANTUM
in each SFQ should be proportional to the bandwidth allocated to that
pool. As per the documents I've read, this must also be >= the
maximum packet size.
I /could/ do that but that'd mean that I have to scan all the pools
beforehand and figure out the weights for each pool, since the weights
are relative. I was hoping that htb.init would do that for me
automatically :)
Another question: wouldn't the QUANTUM only affect the sharing within
a specific pool? Or would it have an impact at the global level
(inter-pool) bandwidth allocation too?
Regards,
-- Raju
--
Raj Mathur raju@kandalaya.org http://kandalaya.org/
GPG: 78D4 FC67 367F 40E2 0DD5 0FEF C968 D0EF CC68 D17F
It is the mind that moves
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [LARTC] [LONG] Weights not working
2003-07-26 4:32 [LARTC] [LONG] Weights not working Raj Mathur
2003-07-26 4:59 ` Rio Martin.
2003-07-26 6:21 ` Raj Mathur
@ 2003-07-29 5:22 ` Rio Martin.
2003-07-29 7:42 ` Stef Coene
3 siblings, 0 replies; 5+ messages in thread
From: Rio Martin. @ 2003-07-29 5:22 UTC (permalink / raw)
To: lartc
On Saturday 26 July 2003 13:09, Raj Mathur wrote:
> Hi Rio,
> Hmm, so if I understand you correctly you're saying that the QUANTUM
> in each SFQ should be proportional to the bandwidth allocated to that
> pool. As per the documents I've read, this must also be >= the
> maximum packet size.
Not quantum value in SFQ, but R2Q ..
Perhaps Stef have something more about this, i am just user, i am just using
this HTB without understanding about how this work more deeper ..
Regards,
Rio Martin.
--
Don't put off for tomorrow what you can do today, because if you enjoy
it today you can do it again tomorrow.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [LARTC] [LONG] Weights not working
2003-07-26 4:32 [LARTC] [LONG] Weights not working Raj Mathur
` (2 preceding siblings ...)
2003-07-29 5:22 ` Rio Martin.
@ 2003-07-29 7:42 ` Stef Coene
3 siblings, 0 replies; 5+ messages in thread
From: Stef Coene @ 2003-07-29 7:42 UTC (permalink / raw)
To: lartc
On Tuesday 29 July 2003 07:22, Rio Martin. wrote:
> On Saturday 26 July 2003 13:09, Raj Mathur wrote:
> > Hi Rio,
> > Hmm, so if I understand you correctly you're saying that the QUANTUM
> > in each SFQ should be proportional to the bandwidth allocated to that
> > pool. As per the documents I've read, this must also be >= the
> > maximum packet size.
>
> Not quantum value in SFQ, but R2Q ..
> Perhaps Stef have something more about this, i am just user, i am just
> using this HTB without understanding about how this work more deeper ..
Quantum is a number of bytes. It is calculated as rate / r2q. And r2q can be
set when you add a htb qdisc (default = 10). Quamtum is the number of bytes
that each class can send when they are fighting for remaining bandwidth.
The minimum quantum is 1500 (max packet size). So you can send at least 1
packet. The maximum is 60000 and this is hard coded in htb to prevent class
starvation. If a class has a quantum of 1000000000 it will send 1000000000
bytes before other classes are served. So to prevent this, 60000 is the
maximum.
The rate of a class is the minimum bandwidth a class will get. If all classes
are sending theire rate AND the parent has more bandwidth, each class may
send quantum bytes. So quantum is only imporant if the parent has more
bandwidth then the sum of the rate of the active child classes.
I never changed quantum in a test situation to see what's happing, but there
are reports that you can improve your setup by choosing the right quantums.
Just take quantum not too small (5000 so you can send some packets in 1
turn). But for higher rates, take a higher quantum. But don't give 2
classes 2 total different quantums like 2000 and 600000.
I hope this helps. I know what quantum does, but if you get some real
improvements if you change quantum, let me know so I can update the faq page
on docum.org.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2003-07-29 7:42 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-07-26 4:32 [LARTC] [LONG] Weights not working Raj Mathur
2003-07-26 4:59 ` Rio Martin.
2003-07-26 6:21 ` Raj Mathur
2003-07-29 5:22 ` Rio Martin.
2003-07-29 7:42 ` Stef Coene
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.