Date: Sun, 7 Feb 2010 20:01:13 +0000 From: RW <rwmaillists@googlemail.com> To: freebsd-questions@freebsd.org Subject: Re: how to control upload data in bittorrent clients Message-ID: <20100207200113.32353635@gumby.homeunix.com> In-Reply-To: <4B6F06EF.5020908@pp.dyndns.biz> References: <SNT111-W34EEE79753C6B98DFFA421B2530@phx.gbl> <4B6DE9D5.8050301@pp.dyndns.biz> <20100207045756.5148b4a0@gumby.homeunix.com> <4B6E8D18.7000609@pp.dyndns.biz> <20100207150212.4e94824c@gumby.homeunix.com> <4B6F06EF.5020908@pp.dyndns.biz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 07 Feb 2010 19:31:11 +0100 Morgan Wesstr=F6m <freebsd-questions@pp.dyndns.biz> wrote: > RW wrote: > > On Sun, 07 Feb 2010 10:51:20 +0100 > > Morgan Wesstr=F6m <freebsd-questions@pp.dyndns.biz> wrote: > >=20 > >> RW wrote: > >>> On Sat, 06 Feb 2010 23:14:45 +0100 > >>> Morgan Wesstr=F6m <freebsd-questions@pp.dyndns.biz> wrote: > >>> > >>> > >>>>> 1) in the transmission web it showing downloading is 10 > >>>>> kbps to 30 kbps but uploading it shows 50 to 92 kbps my > >>>>> question is is it possible to limit the uploading data rate , > >>>>> how can I do this ? > >>>> Check out Daniel Hartmeier's excellent article on how to > >>>> prioritize TCP ACKs (and other traffic). It will explain what > >>>> you experience and solve the problem for you. > >>> It's a good idea to handle this from within transmission too. > >>> Rate limiting works best at the TCP level. > >> Well, the thing is that if you prioritize your TCP ACKs you won't > >> have to do any rate limiting within transmission. You can then use > >> your full upload and download simultaneously. Don't you want to > >> use the bandwidth you pay for? :-) > >=20 > > You can't get the full bandwidth because you need to set the upload > > limit at a level that can be sustained upstream in your router or > > modem; otherwise it doesn't work properly. You can't just use your > > nominal line-speed or let altq pick-up the interface speed. >=20 > You're of course correct. I'm sorry if I didn't specify that but > Daniel's article clearly explains it. The purpose of my response here > was not to describe in detail how to configure ALTQ but merely to > direct the OP to a solution that solves the exact problem he > describes. This phenomenon is very common among people with > asymmetric connections. >=20 > > It depends what you are trying achieve. If your sole object is to > > prevent ack delays reducing tcp download speed then altq will do it. > > However, if you want to seed afterwards you need to reduce the > > impact on latency-sensitive protocols like http and imap. Further > > traffic prioritization does help, but I find that I get better > > results if I also set the client to limit itself a bit below the > > altq limit. >=20 > My personal queue definition is rather complex. Naturally I prioritize > traffic like http, smtp, ssh, rsync, ntp and others over the bulk > traffic produced by bittorrent. Since bandwidth can be borrowed > between queues the bulk traffic is able to use all of my bandwidth > when I don't need it for prioritized traffic. I'm aware of that, and do it, but in practice I find that latency is still improved. YMMV > > In my experience tcp limiting also produces steadier uploads than > > altq so the average rate can actually be higher. >=20 > I have probably been lucky with the ISPs I've used over the years > because they have always delivered a constant and steady upload to > me. It's nothing to do with the ISP, the ISP's the same in both cases.=20 My guess is that ktorrent's limiting tends to spread the uploads more evenly among the peers. > I set up my first PF/ALTQ-based router on OpenBSD, several years > before it was ported to FreeBSD, and I have never looked back since > then. No amount of application speed limiting has ever come close to > produce better bandwidth utilization for me than PF/ALTQ. It's the best of a bad lot, dropping and delaying IP packets is a poor way of regulating TCP.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100207200113.32353635>