From owner-freebsd-questions@FreeBSD.ORG Sun Feb 7 20:01:20 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33CF11065670 for ; Sun, 7 Feb 2010 20:01:20 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id B98138FC0C for ; Sun, 7 Feb 2010 20:01:19 +0000 (UTC) Received: by wwj40 with SMTP id 40so1422446wwj.13 for ; Sun, 07 Feb 2010 12:01:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type:content-transfer-encoding; bh=vQGp5HVKtxBJeBS8qDDH9ZzQahpNQWoSck+EOfbeaSE=; b=RNiiCbyyBd7UuK7QLFnNjRZ+A9uC908BwS40o8FZzU4Y6udPQbGTg70gS1n2faL/AZ tVbWCgS6e6hrgjgz5j/SJfCO3t0xS45ndfKTrskOyRjKglJdkX+bpR4S6efjZJkuh1R8 ydFDA82X9hy6wrJa4CsLsQINvUosR87ATjmj8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type:content-transfer-encoding; b=D1pqA/A4jdDwdhvSlCnNGCbsXZz6mj1Z3bImTO+sXM5croOvG3wld6XsDlCqhp+eHz +fS+cg28rxvDvHcrwPfLtGdlBSePAhBxi0FzqIfkdFHNWvuJh7qHqepOhOLEn3GuLks5 /DhdrXSb79lnePSAX1XARLnXvNK2J0GAtwfvY= Received: by 10.216.85.70 with SMTP id t48mr2126222wee.84.1265572878420; Sun, 07 Feb 2010 12:01:18 -0800 (PST) Received: from gumby.homeunix.com (bb-87-81-140-128.ukonline.co.uk [87.81.140.128]) by mx.google.com with ESMTPS id i35sm9066837gve.11.2010.02.07.12.01.15 (version=SSLv3 cipher=RC4-MD5); Sun, 07 Feb 2010 12:01:16 -0800 (PST) Date: Sun, 7 Feb 2010 20:01:13 +0000 From: RW To: freebsd-questions@freebsd.org Message-ID: <20100207200113.32353635@gumby.homeunix.com> In-Reply-To: <4B6F06EF.5020908@pp.dyndns.biz> References: <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> X-Mailer: Claws Mail 3.7.4 (GTK+ 2.18.6; i386-portbld-freebsd8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: how to control upload data in bittorrent clients X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Feb 2010 20:01:20 -0000 On Sun, 07 Feb 2010 19:31:11 +0100 Morgan Wesstr=F6m wrote: > RW wrote: > > On Sun, 07 Feb 2010 10:51:20 +0100 > > Morgan Wesstr=F6m wrote: > >=20 > >> RW wrote: > >>> On Sat, 06 Feb 2010 23:14:45 +0100 > >>> Morgan Wesstr=F6m 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.