From mboxrd@z Thu Jan 1 00:00:00 1970 From: Vadtec Date: Tue, 04 Sep 2007 13:39:37 +0000 Subject: Re: [LARTC] Question about how TC enforces bandwidth limiting Message-Id: <46DD6019.7080000@vadtec.net> List-Id: References: <46D758ED.2030705@vadtec.net> In-Reply-To: <46D758ED.2030705@vadtec.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org Martin A. Brown wrote: > -----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. > 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, 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. > > Well, a typical torrent client will use a number of connections. > Perhaps some of the connections are classified correctly and some > are not? > 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 traffic 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. > > You 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 traffic > > So, 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. > Bah, I need to figure out outgoing before I mess with incoming. I'm liable to cut my self off from the internet. :P > Snipped iptables classification. Nothing looks fishy to me there > (though I haven't used the iptables CLASSIFY target). > > : $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. > Ok, quantum has always been 1512 for me, so I assume tc is taking care of it. > Good luck, > > - -Martin > > - -- > 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/) > > iD8DBQFG3Vd1HEoZD1iZ+YcRAv0pAKDZ0qtpxyOkGJJQ7H5rWtFi3HlM2gCgrugd > WyARMeCjVI9TD/1CcTTDAsw> =RKrP > -----END PGP SIGNATURE----- > > 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 for 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@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc