From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stef Coene Date: Mon, 28 Jul 2003 17:57:43 +0000 Subject: Re: [LARTC] borrowing+priority, help req Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org 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/