how to control upload data in bittorrent clients

[RW]

On Sun, 07 Feb 2010 19:31:11 +0100
Morgan Wesström <freebsd-questions at pp.dyndns.biz> wrote:

> RW wrote:
> > 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.

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.
> 
> 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. 
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.