Re: [LARTC] tbf and prio blocking some flows entirely

[Andy Furniss <andy.furniss@dsl.pipex.com>]

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