All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andy Furniss <adf.lists@gmail.com>
To: lartc@vger.kernel.org
Subject: Re: Can't get tc to limit network traffic
Date: Mon, 15 Sep 2014 16:03:49 +0000	[thread overview]
Message-ID: <54170DE5.8060601@gmail.com> (raw)
In-Reply-To: <541642D6.4040104@gmail.com>

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

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.


  parent reply	other threads:[~2014-09-15 16:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-15  1:37 Can't get tc to limit network traffic Teresa e Junior
2014-09-15  4:18 ` Mike Schmidt
2014-09-15  5:09 ` Teresa e Junior
2014-09-15  5:49 ` Mike Schmidt
2014-09-15 16:03 ` Andy Furniss [this message]
2014-09-15 16:33 ` Dave Taht
2014-09-15 17:27 ` Andy Furniss
2014-09-15 17:41 ` Dave Taht
2014-09-15 21:56 ` Teresa e Junior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54170DE5.8060601@gmail.com \
    --to=adf.lists@gmail.com \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.