Re: tc htb + prio = very slow link

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2012-05-28 10:58, Andy Furniss wrote:
qdisc bfifo 8043: parent 2:1 limit 1514b

This is the problem - your limit on bfifo is 1514 bytes.

It should work if you use the limit parameter for bfifo and set
something bigger - try limit 20k.

Thank you! This was indeed the culprit. It worked on my previous experiment (50Mbit) because I was shaping the entire link then; this time I'm shaping a VLAN. Thing is, it seems Linux sets txqueuelen to 0 by default for all VLAN interfaces (the physical interface has txqueuelen 1000). Since the default limit for bfifo is calculated from the txqueuelen and MTU of the interface, it defaulted to 1514 bytes.

I changed txqueuelen for the VLAN interface to 20, bfifo now defaults to limit 30280b, and everything works fine.

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?

Generally I don't know how well using prio will work, it may be better
to classify your traffic and use htb to do priority.

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.

You also use default to send to prio, which means that arp will get
shaped - though I have no idea what prio band that will end up in, but
it could cause problems if it ends up getting dropped or delayed too much.

Right. I've improved my setup so that it goes like this:

    tc qdisc add dev dsl root handle 1: prio bands 3

    tc qdisc add dev dsl parent 1:1 bfifo
    tc qdisc add dev dsl parent 1:2 handle 2: prio bands 3
tc filter add dev dsl parent 1: prio 1 protocol arp u32 match u32 0 0 flowid 1:1

    tc qdisc add dev dsl parent 2:1 bfifo
    tc qdisc add dev dsl parent 2:2 bfifo
    tc qdisc add dev dsl parent 2:3 bfifo
tc filter add dev dsl parent 1: prio 2 protocol ip u32 match ip dst 10.172.0.0/16 flowid 1:2

    tc qdisc add dev dsl parent 1:3 handle 3: htb
    tc class add dev dsl parent 3: classid 3:0 htb rate 950kbit
    tc qdisc add dev dsl parent 3:0 handle 10: prio bands 6
    tc qdisc add dev dsl parent 10:1 bfifo
    tc qdisc add dev dsl parent 10:2 bfifo
    tc qdisc add dev dsl parent 10:3 bfifo
    tc qdisc add dev dsl parent 10:4 bfifo
    tc qdisc add dev dsl parent 10:5 bfifo
    tc qdisc add dev dsl parent 10:6 bfifo
tc filter add dev dsl parent 1: prio 3 protocol ip u32 match u32 0 0 flowid 1:3

Here, 1:1 is for ARP, 1:2 is for managing the DSL modem, and 1:3 is for the actual communication over the DSL link. Seems to work fine.

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.

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

My kernel (Debian Unstable 3.2.0-2-amd64) probably doesn't have stab. I'll try using the latest Debian kernel when I can.

Thank you very much for your insight!

--
Etienne Dechamps / e-t172 - AKE Group
Phone: +33 6 23 42 24 82
--
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


[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux