Hi Etienne, On May 28, 2012, at 5:53 AM, e-t172 wrote: > 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. Isn't that what you get when you specify the same rate and ceil value for all cases but increasing priorities? (Plus I guess you would need to set up a filter for each band, but I am out of my league here). > >> 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. I would dare to guess you kernel should be fine (I used to with 3.0.4) but your tc binary (iproute2 package) might be too old. It should be possible to compile your own and run in addition to your disco's; just make sure to give the path to your own tc binary in the script that sets up things. best Sebastian > > 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 -- 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
