From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andy Furniss Date: Sun, 04 Dec 2005 22:07:21 +0000 Subject: Re: [LARTC] tbf and prio blocking some flows entirely Message-Id: <43936899.2090007@dsl.pipex.com> List-Id: References: <1133714168.15937.34.camel@pc.local> In-Reply-To: <1133714168.15937.34.camel@pc.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Patrick McHardy wrote: > Brian J. Murrell wrote: > >> I thought I had this all worked out, but it seems not. The following tc >> configuration: >> >> tc qdisc del dev ppp0 root 2> /dev/null > /dev/null >> tc qdisc add dev ppp0 root handle 1: tbf rate 120kbit burst 1200 limit 1 > > >> But it seems that some outbound flows are being blocked entirely. I >> don't think they are being starved though. Even if they end up in 2:3, >> they should at least be treated fairly. But I am producing a flow to >> 66.1.2.3 which does increment the counters in 2:1 but after a few >> packets the flow stalls: > > > Your burst is too small. It needs to be at least one MTU. Patrick do you know why prio is requeueing here? I see the same testing with (a fixed) Brian's setup. If it's to get length then it's going to be a bit out sometimes with sfq attached - it will also messup sfq fairness whatever the reason. Brian - limit is in bytes though you get away with it here by adding prio/sfq, limit 1 would stop traffic if tbf was alone. Also if you ever try tbf on ethX then burst/mtu/limit need to be your mtu + 14. SFQ causes packet reordering when it perturbs and is best for bulk traffic. I would put a shortish bfifo on interactive class (though in practice you've kindof lost the battle if your interactive has queued, so its sfq should be empty when a packet arrives anyway). Andy. _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc