All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] [REPOST] The woods never end with HTB
@ 2003-08-20 17:54 Raj Mathur
  2003-08-20 19:23 ` Stef Coene
  0 siblings, 1 reply; 2+ messages in thread
From: Raj Mathur @ 2003-08-20 17:54 UTC (permalink / raw)
  To: lartc

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 |<--------> =\x192.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@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] 2+ messages in thread

* Re: [LARTC] [REPOST] The woods never end with HTB
  2003-08-20 17:54 [LARTC] [REPOST] The woods never end with HTB Raj Mathur
@ 2003-08-20 19:23 ` Stef Coene
  0 siblings, 0 replies; 2+ messages in thread
From: Stef Coene @ 2003-08-20 19:23 UTC (permalink / raw)
  To: lartc

On Wednesday 20 August 2003 19:49, Raj Mathur wrote:
> 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 |<--------> =\x192.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.
Can you adapt your script so you have 1 class attached to the cbq qdisc and 
attach all other classes to this class?  Like :
1:0
  1:1
    1:0003
    1:0002
    ...

And you also have 2 classes with classid 1:0004 and 1:0005 ??

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] 2+ messages in thread

end of thread, other threads:[~2003-08-20 19:23 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-08-20 17:54 [LARTC] [REPOST] The woods never end with HTB Raj Mathur
2003-08-20 19:23 ` 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.