From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Thu, 09 Jun 2005 23:02:42 +0000 Subject: Re: [LARTC] nesting htbs Message-Id: <42A8CA92.9070907@dsl.pipex.com> List-Id: References: <39458b08050609033727183846@mail.gmail.com> In-Reply-To: <39458b08050609033727183846@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Edward Smith wrote: > Hello all, > I am running a coop satellite link for my aviation company here in > Iraq. (silly blog www.stardotstar.org). I am running tc with htb > with good success so far. I am working on improving it though and > need some help. Currently I have just 4 classes, syn/ack/ping, > webchat, http, and then other. We are really happy with how this has > improved our ability to call home from our rooms and do video chat. > However, I would like to do a better job of making sure that each > IP is getting a fair share because it seems like sometimes one video > or audio chat bullies another one into slowing down and one guy is > having a great video and audio feed while someone elses audio only is > suffering. I've seen some references to wrr and also to making a > class for each IP. There doesn't seem to be much current documention > on wrr, so I'm trying to set up nested htbs. Here are my questions: > > 1. Which makes more sense, to nest my 4 classes of traffic inside of a > class for each IP, or to make a class for each IP in each of my 4 > classes. I'm leaning towards the latter so that someones web traffic > can't borrow from the interactive traffic classes. I would do the latter also. I would have just one interactive class and give it a rate that is say 3/4 of the ceil, the bulk classes can still borrow the unused. > > 2. I've done a test, and can't get any traffic into the nested > classes. Here is my code: > > #1:20 LOW DELAY--CHAT DATA > #includes the minimize delay FW TOS > tc class add dev ${UPDEV} parent 1:1 classid 1:20 htb rate 200kbit > ceil ${UPCEIL}kbit burst 6k prio 1 > tc filter add dev ${UPDEV} protocol ip parent 1: pref 20 u32\ > match ip tos 0x10 0xff flowid 1:20 > tc filter add dev ${UPDEV} protocol ip parent 1: pref 21 handle 5 fw > classid 1:20 > tc filter add dev ${UPDEV} protocol ip parent 1: pref 21 handle 6 fw > classid 1:20 > tc qdisc add dev ${UPDEV} parent 1:20 handle 120: sfq perturb 10 > nextclass 00 You don't need this as it's not a leaf. > for clientip in `cat /etc/ethers | awk '{ print $2 }'`; > do If clientip is local because you are NATing than it won't work because traffic will have the real ip here. To work around you could use marks. As you already use them for some things you may want to use --or-mark and u32 to match them eg. iptables -A POSTROUTING -t mangle -p icmp -j MARK --set-mark 0x0100 and so on for traffic types using high byte then use low byte and --or-mark for addresses iptables -A POSTROUTING -t mangle -s 192.168.0.1 -j MARK --or-mark 0x0001 Then filter top level with a mask like tc filter add dev eth0 parent 1:0 protocol ip prio 1 u32 match mark 0x0100 0xff00 flowid 1:20 and leaf levels tc filter add dev eth0 parent 1:20 protocol ip prio 1 u32 match mark 0x0001 0x00ff flowid 1:200 That assumes you really need iptables for marking traffic type - if you could use tc filters for that, then just use iptables for the addresses. > tc class add dev ${UPDEV} parent 1:20 classid 1:${nextclass} > htb rate ${CLIENTRATE}kbit ceil ${CLIENTCEIL}kbit > tc filter add dev ${UPDEV} protocol ip parent 1:20 prio 1 u32 \ > match ip src ${clientip} flowid 1:${nextclass} > tc qdisc add dev ${UPDEV} parent 1:${nextclass} handle > ${nextclass}: sfq perturb 10 #not sure if this is necessa > ry I wouldn't put sfq on interactive - I would add a bfifo so I could set and play with the buffer lengths. Andy. _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc