-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings again,
: $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).
Yes, exactly. You grasped this below, too. Recall that you can
only shape what you transmit? Think about why. If you already have
a packet, you can delay the transmission. This is the fundamental
behaviour of all non-work conserving queues. To introduce a delay
to a packet involves work.
: 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.
Be careful. Shaping and policing are two very different things. I
probably could have chosen a word other than "policy" to make this
clear. I'll restate this.
If you wish to shape upload traffic, then you must put your traffic
control structures on the the device closest to the Internet. If
you wish to shape download traffic, then you must put your traffic
control structures on the device closest to the internal network(s).
( If you would like to see how you can break this basic rule, see
some advanced traffic control structures called imq and ifb [*]. )
: So, what you are saying is, its just a matter of different
: naming. In essence, 368kbps (conventional) is the same as 368kbit
: (tc), right?
Bingo.
: I have no idea what that means. How do I vary the depth of the
: FIFO to help control latency?
OK, in order to vary the exact depth of the fifo to suit your fancy,
you'd need to use terminal FIFOs instead of using terminal SFQs:
tc qdisc add dev $INTERFACE parent 10:1 handle 100:0 pfifo limit 10
Assuming your HTB tree has a leaf class of 10:1, into which you have
classified some of your traffic, you now have a very short queue
there. If a burst of traffic involving more than ten packets
arrives, the traffic will tail drop. In heavily congested
situations, this can be useful, although this still allows for a
single dominating UDP flow, so I'd probably prefer the SFQ solution,
and maybe I shouldn't have brought up this little trick.
: 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.
If you expect that the torrential traffic to appear in class 100,
and it does not, then you have done something wrong in your
classifier. Look there.
: 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?
Try looking at your classifiers ("tc filter" statements) to
determine where the problem is. If you can't figure it out, then
send the list your classifiers and class structure (tc commands).
I'd skip playing with terminal FIFOs at first (if ever). Try
working on the following:
* switch the units to kbit
* fix the classifiers and verify that you are seeing all traffic
in the class you want to see the traffic in
* turn the torrent client up to "insane" and watch how your IRC or
ssh latency is very low
Good luck,
- -Martin
[*] IMQ, intermediate queuing device
http://www.linuximq.net/
IFB, intermediate functional block
http://linux-net.osdl.org/index.php/IFB
- --
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/)
iD4DBQFG3L5sHEoZD1iZ+YcRAso6AJjnbMjcso8t4+GugFC6eHQOyqJQAJ9kpWbZ
sOS369AbZkPQ9rg3rhiawg==
=gvDh
-----END PGP SIGNATURE-----
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
