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@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
