Hi Andy,
On May 29, 2012, at 8:50 AM, Andy Furniss wrote:
> 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.
And right you are, looking the iproute2's (v 3.4.0) tc_core.c it is clear that link layer ATM will figure out how many ATM cells make up a package and adds number of cells times the 5 byte per cell header size to the effective size. This automatically means the effective mpu is 53 bytes without specifying it. Thinking it through, specifying mpu 53 actually gets extended to min size of 106 or 2 ATM cells, so if at all mpu 48 should be specified. (Then I assume most packets are longer than 30 bytes (so 48 bytes with the specified overhead of 18) and then there is no error left). Learned something new today, thanks.
So to summarize if using ATM based DSL links add the following to lines in which you add the root discs (for egress and ingress if you want to):
stab overhead ${LOOK_THIS_UP_in_man_tc-stab} linklayer atm
The overhead is important to get right but the tc-stab man page section typical overheads is quite helpful there; the tricky thing is more to figure out the properties of the underlaying ATM link...
(mtu and tsize could be used to specify a smaller size table that takes into account the coarser quantization due to ATM cells, but since I already fudged the mpu issue I will avoid trying to be clever here :) )
best
sebastian
>
> 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
--
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
