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 ***
DEFAULT=30
*** eth0-0003,upload ***
RATE=64Kbps
PRIO=5
*** eth0-0003:0003.192.168.0.64.upload ***
RATE=8Kbit
CEIL=20Kbit
PRIO=5
LEAF=sfq
MARK=3
*** eth0-0003:0004.192.168.0.2.upload ***
RATE=32Kbit
CEIL=64Kbit
PRIO=5
LEAF=sfq
MARK=1
*** eth0-0003:0005.192.168.0.3.upload ***
RATE=8Kbit
CEIL=20Kbit
PRIO=5
LEAF=sfq
MARK=2
*** eth1 ***
DEFAULT=30
*** eth1-0002.download ***
RATE=256Kbps
PRIO=5
*** eth1-0002:0003.192.168.0.64.download ***
RATE=32Kbit
CEIL=128Kbit
PRIO=5
LEAF=sfq
MARK=65539
*** eth1-0002:0004.192.168.0.2.download ***
RATE=128Kbit
CEIL=256Kbit
PRIO=5
LEAF=sfq
MARK=65537
*** eth1-0002:0005.192.168.0.3.download ***
RATE=32Kbit
CEIL=128Kbit
PRIO=5
LEAF=sfq
MARK=65538
*** 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/
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/
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/
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/
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/