Re: Can't get tc to limit network traffic

Linux Advanced Routing and Traffic Control

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

 



On Mon, Sep 15, 2014 at 7:03 PM, Andy Furniss <adf.lists@xxxxxxxxx> wrote:
> Teresa e Junior wrote:
>
>> #!/bin/sh
>>
>> tc qdisc del dev ifb0  root
>> tc qdisc del dev wlan0 ingress
>>
>> modprobe ifb
>>
>> tc qdisc  add dev ifb0 root handle 1: prio
>> tc qdisc  add dev ifb0 parent 1:1 handle 10: sfq
>> tc qdisc  add dev ifb0 parent 1:2 handle 20: tbf rate 20kbit \
>>    buffer 1600 limit 3000
>> tc qdisc  add dev ifb0 parent 1:3 handle 30: sfq
>> tc filter add dev ifb0 protocol ip pref 1 parent 1: handle 1 fw classid
>> 1:1
>> tc filter add dev ifb0 protocol ip pref 2 parent 1: handle 2 fw classid
>> 1:2
>
>
> Well handle 2 would need iptables mark 2 - and I don't think using iptables
> is needed anyway.
>
> Using tc to set it, historically at least, has been a bit hit and miss
> requiring matching versions of things.
>
> TBH this all seems over complicated if all you want to do is send all ipv4
> to ifb0 and limit to a couple of meg.
>
> Adding a child of sfq or fq_codel will help stop bulk flows blocking eg dns.
>
> I must admit I made up the params for fq_codel below - maybe someone will
> suggest better for 2mbit rate.
>
> tc qdisc add dev ifb0 root handle 1:0 htb default 1
> tc class add dev ifb0 parent 1:0  classid 1:1 htb rate 2mbit
> tc qdisc add dev ifb0 parent 1:1 handle 10: fq_codel noecn target 50ms
> interval 100ms

the fq_codel internet draft[1] suggests that "interval"

SHOULD be set on the order of the worst-case RTT
   through the bottleneck to give end-points sufficient time to react.

so if you are using a satellite comms system, use 1200ms as the interval,
if you are in new zealand, use 240ms, for most of the rest of the world, 100ms
is the default and "good enough".

As for "interval"

The default target value is 5 ms, but this value SHOULD be tuned to
   be at least the transmission time of a single MTU-sized packet at the
   prevalent egress link speed (which for e.g. 1Mbps and MTU 1500 is
   ~15ms).

and should be 5-10% of the interval, regardless. We hope to remove the
target parameter entirely in some future version of codel - it's actually
the interaction with tbf/htb/hfsc which buffers up an extra packet
 here that requires it be increased at very low bandwidths.

So in this case, 2mbit, a target 8ms would be sufficient. It doesn't
hurt to go bigger, but 50ms is overmuch.

As for ecn, there is generally little harm in leaving it on, and some
benefit, particularly at higher rates and longer RTTs, but
you have to ecn enable the rest of your network to suit [2]

[1] http://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-00#section-4.1.1
[2] http://www.ietf.org/proceedings/89/slides/slides-89-tsvarea-1.pdf


> I would just delete the action xt line from below.
>
>> tc qdisc  add dev wlan0 ingress
>> tc filter add dev wlan0 parent ffff: protocol ip prio 10 u32 \
>>    match u32 0 0 flowid 1:1       \
>>    action xt -j MARK --set-mark 1 \
>>    action mirred egress redirect dev ifb0
>
>
> More generally I am guessing you are limiting this box to stop it hogging
> the wan bandwidth rather than wireless lan.
>
> If the download speed of the wan is not much higher than what you set you
> may need to set lower.
>
> Wherever/however you shape incoming from wan you need to back off as you are
> at the wrong end of the bottleneck.
>
> How much you have to back off depends on how hard you hit the connection eg
> if your box is downloading one tcp it will work closer to the limit than 100
> tcps spread out all over the place like bittorrent.
>
>
> --
> 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



-- 
Dave Täht

https://www.bufferbloat.net/projects/make-wifi-fast
--
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