e-t172 wrote:
I'm curious, however: how do I calculate the optimal txqueuelen value?
Practically speaking, what are the pros and cons of txqueuelen 20 versus
e.g. txqueuelen 1000? I'm guessing this has to do with TCP congestion
control?
I don't know really. Not too long and not too short :-)
I suppose if you are doing qos and separating interactive from bulk and
also can use sfq for bulk fairness then long buffers are OK.
If you are mixing interactive and bulk then you and up with long delays
- but then with short buffers you may drop some interactive.
Googling bufferbloat will show that people think buffers are getting too
long.
Well, AFAIK HTB requires me to specify rates for all classes, whereas I
just want strict prioritization. I don't care if the lower classes
starve while the upper queues are congested. I want them to starve,
actually.
OK fair enough/
Right. I've improved my setup so that it goes like this:
<snip>
I've never used/tested a setup like this, but as long as it works...
Surprisingly, the first filter (protocol arp) doesn't match if I use
arping, but it matches if I trigger an ARP request using arp -d. Strange.
No idea about that - maybe because dsl is a vlan - I take it that
tcpdump on dsl also doesn't show anything with arping.
As Sebastian says you could also investigate stab.
Mmmh…
# tc qdisc add dev dsl root handle 1: stab overhead 18 mtu 2048 mpu 53
linklayer atm
RTNETLINK answers: No such file or directory
You would use this on your top level htb - so if you were adding htb to
your root then just putting htb on the end of the above should work.
I wouldn't specify mpu 53 - atm should handle that and it probably gets
applied before that so may make some tiny packet not fit in one cell.
It's a long time since I tested vlans - maybe instead of taking 14 as
for eth you could take 18 from your overhead. You would have to test htb
byte counters and see if traffic was getting +14 or +18 added to IP as
seen by htb.
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
