From: Vadtec <vadtec@vadtec.net>
To: lartc@vger.kernel.org
Subject: [LARTC] Question about how TC enforces bandwidth limiting
Date: Mon, 03 Sep 2007 12:05:53 +0000 [thread overview]
Message-ID: <46DBF8A0.5080504@vadtec.net> (raw)
In-Reply-To: <46D758ED.2030705@vadtec.net>
Hello,
I run one of my PCs as my personal router, with iptables+tc to control
traffic and be my firewall.
In TC, I use a combination of htb, qdisc and sfq (as well as prio) to
classify bandwidth. In my current setup, I have 10 classifications of my
bandwidth. (Even I admit this is probably more than I need, but at this
point I'm still learning, so I'll just leave them be.) This leads me to
my question about how TC enforces maximum bandwidth limits.
I am on DSL internet with rates 1.5Mbps/384kbps. I do not make complete
use of my pipe just in case of a massive burst. I know I will probably
not burst such a massive burst, but its better to be safe than sorry.
To help understand this, here are the classes and their associated
bandwidths as I have them set in TC:
(MAX_RATE is 360kbps)
$TC qdisc add dev $IFext root handle 1: htb default 90
$TC class add dev $IFext parent 1: classid 1:1 htb rate $MAX_RATE
quantum $QUANTUM
$TC class add dev $IFext parent 1:1 classid 1:10 htb rate 240kbps
ceil $MAX_RATE prio 0 quantum $QUANTUM
$TC class add dev $IFext parent 1:1 classid 1:20 htb rate 192kbps
ceil $MAX_RATE prio 1 quantum $QUANTUM
$TC class add dev $IFext parent 1:1 classid 1:30 htb rate 80kbps ceil
$MAX_RATE prio 2 quantum $QUANTUM
$TC class add dev $IFext parent 1:1 classid 1:40 htb rate 64kbps ceil
$MAX_RATE prio 3 quantum $QUANTUM
$TC class add dev $IFext parent 1:1 classid 1:50 htb rate 32kbps ceil
$MAX_RATE prio 4 quantum $QUANTUM
$TC class add dev $IFext parent 1:1 classid 1:60 htb rate 20kbps ceil
$MAX_RATE prio 5 quantum $QUANTUM
$TC class add dev $IFext parent 1:1 classid 1:70 htb rate 16kbps ceil
$MAX_RATE prio 6 quantum $QUANTUM
$TC class add dev $IFext parent 1:1 classid 1:80 htb rate 8kbps ceil
$MAX_RATE prio 7 quantum $QUANTUM
$TC class add dev $IFext parent 1:1 classid 1:90 htb rate 2kbps ceil
$MAX_RATE prio 8 quantum $QUANTUM
$TC class add dev $IFext parent 1:1 classid 1:100 htb rate 2kbps ceil
20kbps prio 9 quantum $QUANTUM
$TC qdisc add dev $IFext parent 1:10 handle 10: sfq perturb 10
$TC qdisc add dev $IFext parent 1:20 handle 20: sfq perturb 10
$TC qdisc add dev $IFext parent 1:30 handle 30: sfq perturb 10
$TC qdisc add dev $IFext parent 1:40 handle 40: sfq perturb 10
$TC qdisc add dev $IFext parent 1:50 handle 50: sfq perturb 10
$TC qdisc add dev $IFext parent 1:60 handle 60: sfq perturb 10
$TC qdisc add dev $IFext parent 1:70 handle 70: sfq perturb 10
$TC qdisc add dev $IFext parent 1:80 handle 80: sfq perturb 10
$TC qdisc add dev $IFext parent 1:90 handle 90: sfq perturb 10
$TC qdisc add dev $IFext parent 1:100 handle 100: sfq perturb 10
Class 90 is the default. Class 100 is a special class, and what my
question specifically relates to. Class 100 is for bit torrent. I do not
like the other people in my house using very much bandwidth for
torrenting as it has a tendency to slow things down to greatly. The
problem I have is this: when I disable a given torrent clients upload
limits, the bandwidth climbs to above the 20kbps limit I have set for
it. When I classify the traffic in iptables, i put it into class 100, so
it shouldn't getting put into the default class.
While I understand how/why TC enforces minimum bandwidth for a given
class, why is it that for class 100 TC is not enforcing the cap of
20kbps to traffic that it is classified at? Is there something else I
need to do to make TC also enforce arbitrary maximum limits for a given
classification?
Vadtec
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
next prev parent reply other threads:[~2007-09-03 12:05 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-30 23:55 [LARTC] Question about how TC enforces bandwidth limiting Vadtec
2007-09-03 12:05 ` Vadtec [this message]
2007-09-03 18:43 ` Martin A. Brown
2007-09-03 20:15 ` Vadtec
2007-09-04 2:09 ` Martin A. Brown
2007-09-04 12:27 ` Vadtec
2007-09-04 13:02 ` Martin A. Brown
2007-09-04 13:39 ` Vadtec
2007-09-06 1:13 ` Vadtec
2007-09-06 2:47 ` Martin A. Brown
2007-09-06 3:04 ` Vadtec
2007-09-06 4:08 ` Vadtec
2007-09-06 17:43 ` Vadtec
2007-09-06 17:57 ` David Boreham
2007-09-06 18:43 ` Vadtec
2007-09-06 19:32 ` David Boreham
2007-09-06 20:09 ` Vadtec
2007-09-06 20:09 ` Andy Furniss
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=46DBF8A0.5080504@vadtec.net \
--to=vadtec@vadtec.net \
--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.