Re: Question about how TC enforces bandwidth limiting
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
Martin A. Brown wrote:
Can you provide a simple example of how to filter with tc rather than iptables? Just enough of an idea for me to grasp it on my own. I think it would be better to use tc to do the filtering rather than iptables,-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Good morning,: I ran "tc filter" on the command line, but received no output in : return. I read the man page and it leads me to believe that it's : not meant for viewing the filters.Depends, but yes, the "tc filter" output is not necessarily attractive. You can classify with "tc filter" instead of iptables, but if you reach your goal, it doesn't matter which mechanism you use to classify your packets.
as thats what tc is meant to do.
: One thing I did notice was, while I did see traffic in class 100 : for the first time, my torrent client still showed outgoing : bandwidth of more than 20kbit.One thing I had failed to take into account was the possibility that bit torrent *may* be using some UDP ports. In an attempt to test this theory, I added the udp filters to iptables and watched the data stream. No change. -_- Bit torrent is still showing outgoing speeds of above 20k. So, I then limitted the filter to the LAN IP for my router box and forced my torrent client to use that IP. Still above 20k. Long story short, I tried about 5 different things to get it to work properly. No luck. I think part of the problem is that my torrent client doesn't seem to honor the port ranges I put into effect. Which would definitely allow trafficWell, a typical torrent client will use a number of connections. Perhaps some of the connections are classified correctly and some are not?
to get past it.
: Is this simply a function of the router actually limiting the : traffic and the torrent client simply not knowing? Or (and I : assume this is incorrect thinking) should the torrent client : visibly indicate to me that it can only send at X rate because : its limited?I would expect the torrent client to be reporting the actual speed(s), so I would expect it to be reporting 20kbit rates.
As would I.
: To make this much simpler, I will paste my tc rules and iptables : rules (which classify my traffic) at the bottom of this e-mail. I : hope you can find something (related specifically to bit torrent) : that will allow me to limit torrent traffic without the need to : limit each client by hand.Bah, I need to figure out outgoing before I mess with incoming. I'm liable to cut my self offYou are getting there.: So I am at a total loss as to why (outgoing) SSH traffic would : become so slow, because it has access to more bandwidth than : torrent (at least in my thinking).Are you sure that it's outgoing SSH traffic that is slow? Consider the following scenario:* your outgoing queues are configured completely correctly * outgoing ssh IP packet gets into correct queue * inbound return IP packet from ssh server is delayed inbound because you are not shaping downstream trafficSo, before you conclude that your shaping isn't working, I think you'll need to apply some sort of mechanisms also on your internal interface.
from the internet. :P
Snipped iptables classification. Nothing looks fishy to me there (though I haven't used the iptables CLASSIFY target).Ok, quantum has always been 1512 for me, so I assume tc is taking care of it.: $IFext is of course eth0 (link to the modem), $QUANTUM is 1490 : (due to, if I assume correctly, my MTU being 1492, in the modem), : $MAX_RATE is 360kbit (360kbps conventional talk)I wouldn't set quantum unless you need to do so. HTB will calculate this for you. If you do need to set the quantum, I'd recommend setting it just a bit larger than the MTU...so 1500 or 1536 in your pppoe situation.
So, I am at a total loss as to why this isn't working. Well, not a total loss, but enough of a total loss as to disable some of the shaping I had been using that was giving me fits. I think it's much better forGood luck, - -Martin- -- Martin A. Brownhttp://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/) iD8DBQFG3Vd1HEoZD1iZ+YcRAv0pAKDZ0qtpxyOkGJJQ7H5rWtFi3HlM2gCgrugd WyARMeCjVI9TD/1CcTTDAsw= =RKrP -----END PGP SIGNATURE-----
me to let the default class handle everything and go from there for now.As I said above, can you provide a simple example of how to filter with tc? I think filtering in tc will be
both more appropriate and less hassling.I really appreciate you taking the time to help me with this. I am by no means a noob to networking, but when it comes to traffic shaping, I might as well be. Though, on a positive note, at least I've been able to properly shape some traffic, like IRC. :) (I'm also going to contact the developers of my torrent client and ask them about port range limiting. And why it doesn't seem to be working.)
Thanks again, Vadtec _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc