Re: Question about how TC enforces bandwidth limiting

Linux Advanced Routing and Traffic Control

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

 



Martin A. Brown wrote:
-----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!
Not at all. :)
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:
$IFext is eth0, and is my link to my DSL Modem. $IFint would be eth1, which is my interface to my LAN (though I am not shaping traffic on it in any way). Both of these devices plug into my 24 port switch, which the DSL modem is hooked into, as well as all the other computers in
the house.

So just for clarity sake, here are the port assignments on the switch:
Port 1 - DSL Modem uplink
Port 2 - $IFext (eth0) on my router PC
Port 3 - $IFint (eth1) on my router PC
Port 4 - My laptop
Port 5 - My brothers PC
Port 6/25 - Unused currently, but used at random as needed.
* 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.
So you are saying I have to not only do traffic shaping, but also traffic policing on my internal device? Or do I have to do traffic shaping on both devices and no traffic policing? In other words, how much traffic shaping/policing do I need to put into effect, and on which interfaces.
: 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].
So, what you are saying is, its just a matter of different naming. In essence,
368kbps (conventional) is the same as 368kbit (tc), right?
: 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.
I have no idea what that means. How do I vary the depth of the FIFO to help control latency?
: 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.
I ran both watch -n 1 tc -s class show dev eth0 and watch -n 1 tc -s qdisc show eth0. (When I ran class show, i did not have enough room to see classes 80 and 90. When I ran qdisc show, I was able to see all the classes.) During my runs of tc in this manner, I saw zero traffic going to class 100 when running, starting, or stopping bit torrent. Almost all the traffic was going to class 10 and 90 (default) with the exception of my ICMP and UDP traffic which was going to class 70 and class 60 which I have set aside for IRC traffic. Class 100 saw absolutely zero traffic.

Is this a case where the default class (90) is getting all the traffic because it can handle it as my LAN has very little "other" traffic most of the time to deal with, so there is no need to throttle it back? If so, how can I force a particular class to be used regardless of the default,
so that I can control individual apps by them selves?
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-----


Thank you for your help!

Vadtec
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux