Re: [LARTC] borrowing+priority, help req

From: Stef Coene <stef.coene@docum.org>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] borrowing+priority, help req
Date: Mon, 28 Jul 2003 17:57:43 +0000	[thread overview]
Message-ID: <marc-lartc-105941570415139@msgid-missing> (raw)
In-Reply-To: <marc-lartc-105903125214535@msgid-missing>

On Thursday 24 July 2003 09:19, Andras.Horvath@cern.ch wrote:
> Hi!
>
> I'm new to this list :) I have a problem (or misunderstanding) trying to
> set up the very basic example: giving priority to outgoing traffic from
> a host (on 100Mbit Ethernet) towards a subset of nodes based on their IP
> address (not on QoS flags), while allowing others to use all 'leftover'
> bandwidth.
>
> I have tried with htb and cbq qdiscs as well and neither seems to be
> doing what I want. :) Here is my CBQ setup:
>
> tc qdisc add dev eth1 root handle 1:0 cbq bandwidth 100Mbit \
> 	 rate 100Mbit avpkt 1000 cell 8
> tc class add dev eth1 parent 1:0 classid 1:1 cbq bandwidth 100Mbit rate
> 100Mbit \ weight 1Mbit prio 8 allot 1514 cell 8 maxburst 20 avpkt 1000
> bounded tc class add dev eth1 parent 1:1 classid 1:3 cbq bandwidth 100Mbit
> rate 80Mbit \ weight 0.8Mbit prio 5 allot 1514 cell 8 maxburst 20 avpkt
> 1000
> tc class add dev eth1 parent 1:1 classid 1:4 cbq bandwidth 100Mbit rate
> 20Mbit \ weight 0.2Mbit prio 5 allot 1514 cell 8 maxburst 20 avpkt 1000
> tc qdisc add dev eth1 parent 1:3 handle 30: sfq
> tc qdisc add dev eth1 parent 1:4 handle 40: sfq
> tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match \
> 	ip dst 10.0.0.0/16 flowid 1:3
> tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match \
> 	ip dst 10.1.0.0/16 flowid 1:4
>
> What this simply does for me is that when both IP ranges start
> 'fighting' for bandwidth they get about 50% each while as I understood
> (? :) from the HOWTO they should have got a 8:2 ratio.
> If I make one of 1:3 or 1:4 'bounded', the other is able to borrow its
> bandwidth, but not the other way around (no surprise).
>
> I tried the prio qdisc too:
>
> tc qdisc add dev eth1 root handle 1: prio
> tc qdisc add dev eth1 parent 1:1 handle 10: sfq perturb 10
> tc qdisc add dev eth1 parent 1:2 handle 20: sfq perturb 10
> tc qdisc add dev eth1 parent 1:3 handle 30: sfq perturb 10
> tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match \
> 	ip dst 10.1.0.0/16 flowid 1:3
> tc filter add dev eth1 parent 1: protocol ip prio 1 u32 match \
> 	 ip dst 10.0.0.0/16 flowid 1:1
>
> which seems to have 'no effect' as well (50% bandwidth goes to both
> parties).
>
> The packets indeed make it to the right class/qdisc according to tc -s.
> Measurements were taken using iptables counters.
>
> Could you help me (either by pointing out where I don't understand
> something or providing a working example)?
See docum.org for examples.
You can try to shape your total bandwidth to 95mbit.   So YOU are the 
bottleneck and not the network.

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/