-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Vadtec,
I think you may be making two of the most common problems facing
novices working with traffic control, so I hope you don't mind my
picking on you!
Problem #0
- ----------
You are applying your shaping on the outbound traffic (presuming
that "$IFext" is your external interface. Unless you also have
shaping on your inbound traffic ("$IFint"?), then you are only
applying shaping characteristics to the upload traffic. This brings
us back to two fundamental rules of traffic shaping:
* For optimal results, your shaping device should be the
bottleneck, so that it can act as the traffic flow valve.
* You can only shape what you transmit. If your edge device is
performing shaping, then it should shape upload traffic by a
policy applied to the external interface and it should shape
download traffic by policy applied to the internal interface.
In short, add a similar set of HTB + SFQ queues to your internal
interface, along with the appropriate classifiers and try again.
: 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?
:
: I am on DSL internet with rates 1.5Mbps/384kbps.
That 1.5Mbps (conventional networking terminology and units) is
written as 1.5Mbit in terms used by tc.
Problem #1
- ----------
I think you may be making an error in your units. This is one of
the most frequent problems when people start using "tc". Since "tc"
sprang from the primordial soup, the following units are used:
bps = bytes per second
bit = bits per second
The unfortunate problem with this marking for units is that we say
many other places in networking that bits per second is bps. This
is not true with tc. So, if I look at your rate specifications
below, they look off by a factor of 8. Please try altering all
instances of "kbps" to "kbit" and try your script again. See also
these URLs [0] [1] [2].
: 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.
This is wise.
: 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.
If you place FIFOs in any of your HTB leaf classes, you can vary the
depth of the FIFO queue to help control latency, in addition to that
class's total throughput. This is a cheap and dirty way to
accomplish this task.
: 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 you are starting and stopping your torrent client, you should
also take a look at the class statistics:
watch -n 1 tc -s class show dev $INTERFACE_NAME
This will allow you to see which class is being used to carry that
traffic.
Good luck,
- -Martin
[0] http://www.docum.org/docum.org/faq/cache/74.html
[1] http://mailman.ds9a.nl/pipermail/lartc/2003q4/010826.html
[2] http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm
- --
Martin A. Brown
http://linux-ip.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/)
iD8DBQFG3FYGHEoZD1iZ+YcRAr3NAKC2Iq1mtkEwd3edzU8mY6CQx/PuKgCggE0F
hcIyU0L25TYNwMkXGcjusWw=
=ifyk
-----END PGP SIGNATURE-----
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
