[LARTC] [REPOST] The woods never end with HTB

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

After spectacularly failing to get HTB to proportionately distribute
excess bandwidth into multiple classes based on the rate, I decided to
hack my requirements.  Now I'm creating multiple classes with the sum
of the bandwidths of the classes being equal to (OK, slightly less
than) the link bandwidth.

Scenario:

                   Linux Router
+------+ 256K  +-------------------------+   10M
| VSAT |<----->|10.9.25.34   192.168.0.1 |<--------> ===192.168.0.0/24 LAN===
+------+       +-------------------------+
                eth0                 eth1

Packets are being NATed on the Linux machine, and being policed/shaped
at each interface.  Incoming traffic is shaped on the 192.168.0.1
(eth1) interface, outgoing traffic on eth0.

When a single host is accessing the Internet things are just fine.  It
gets bandwidth upto its rate (which is the same as its ceil).  However
as soon as another host joins the download party the first host's
bandwidth starts dropping until it ends up somewhere in the vicinity
of 1/3 of its rate.  I've tried pfifo, bfifo, no leaf at all and SFQ
as leaves, all of which demonstrate the same behaviour.  There's no
lack of bandwidth on the VSAT end, so this behaviour is completely
inexplicable.

Sharing of bandwidth between hosts within a class is working just
fine.

Using the iptables mark facility to classify the packets for bandwidth
control.  The marks are working fine, since tc -s displays correct
statistics on each class.

The script I'm using for traffic control (HTB.init-generated) is:

tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1 htb default 4

tc qdisc del dev eth1 root
tc qdisc add dev eth1 root handle 1 htb default 4

tc class add dev eth0 parent 1: classid 1:0003 htb rate 64Kbit prio 5

tc class add dev eth0 parent 1:0003 classid 1:0004 htb rate 12.1904761904762Kbit ceil 12.1904761904762Kbit 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 2 fw classid 1:0004

tc class add dev eth0 parent 1:0003 classid 1:0005 htb rate 39.0095238095238Kbit ceil 39.0095238095238Kbit 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 1 fw classid 1:0005

tc class add dev eth1 parent 1: classid 1:0002 htb rate 256Kbit prio 5

tc class add dev eth1 parent 1:0002 classid 1:0004 htb rate 68.2666666666667Kbit ceil 68.2666666666667Kbit 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 65538 fw classid 1:0004

tc class add dev eth1 parent 1:0002 classid 1:0005 htb rate 136.533333333333Kbit ceil 136.533333333333Kbit 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 65537 fw classid 1:0005

To be specific, the host in class 1:0005 on eth1 downloads at the full
136Kbps on its own.  As soon as any host in the 1:0004 class starts
downloading, however, the bandwidth of the 1:0005 host drops to some
50-60Kbps. 

Is there something very obvious that I'm missing?  Any light on this
issue would be a great help.

Regards,

-- Raju
-- 
Raj Mathur                raju@xxxxxxxxxxxxx      http://kandalaya.org/
       GPG: 78D4 FC67 367F 40E2 0DD5  0FEF C968 D0EF CC68 D17F
                      It is the mind that moves


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux