how to control upload data in bittorrent clients
freebsd-questions at pp.dyndns.biz
Sun Feb 7 18:31:15 UTC 2010
> On Sun, 07 Feb 2010 10:51:20 +0100
> Morgan Wesström <freebsd-questions at pp.dyndns.biz> wrote:
>> RW wrote:
>>> On Sat, 06 Feb 2010 23:14:45 +0100
>>> Morgan Wesström <freebsd-questions at 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? :-)
> 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.
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.
> 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.
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.
> In my experience tcp limiting also produces steadier uploads than altq
> so the average rate can actually be higher.
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. 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.
More information about the freebsd-questions