From owner-freebsd-ipfw@FreeBSD.ORG Wed Nov 3 09:57:09 2004 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7066216A4CE for ; Wed, 3 Nov 2004 09:57:09 +0000 (GMT) Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE3F643D46 for ; Wed, 3 Nov 2004 09:57:08 +0000 (GMT) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: by shellma.zin.lublin.pl (Postfix, from userid 1018) id D240F3474C1; Wed, 3 Nov 2004 10:57:49 +0100 (CET) Date: Wed, 3 Nov 2004 10:57:49 +0100 From: Pawel Malachowski To: freebsd-ipfw@freebsd.org Message-ID: <20041103095749.GA56028@shellma.zin.lublin.pl> References: <20041031203558.GA49557@shellma.zin.lublin.pl> <20041102223835.B42486@xorpc.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20041102223835.B42486@xorpc.icir.org> User-Agent: Mutt/1.4.2i Subject: Re: [PATCH] burstable dummynet pipe X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: freebsd-ipfw@freebsd.org List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Nov 2004 09:57:09 -0000 On Tue, Nov 02, 2004 at 10:38:35PM -0800, Luigi Rizzo wrote: Helo, > > Configuring `x bytes burst' means we are allowing to transmit x bytes > > with increased (by default: ~2x) speed. After that, traffic passes > > through pipe as usual (bw-limited), however, burst credit is slowly > > (by default: ~10x lower than bw) accumulated when pipe is idle (low > > to tell the truth, the 2x and 10x thing seems to me a rather > kludgy and arbitrary way to implement 'bursts'. > The most straightforward way to implement this feature is > to let the pipe be "burst" bytes ahead of the programmed rate, > which results in a rather trivial change to the current code. > If you really want to burst out data and recover credt at a > different rate, these extra rates should be configurable. Fully agree, these values are hardcoded because this is a concept preview, and as I wrote, this is a poor patch. It also won't work for pipes connected with WFQ queues (but I'm not too sure if it is worth implementing). > so if someone thinks of committing this patch in the current form, > please at least note in the commit log that i am opposed to that. Commiting it like this is a bad idea. I've posted this here only to see if someone is interested and maybe can pick it up. Since I do not even know C language, I'm not a proper person to implement this. I've made this patchset having two things in mind: . small burst may be a good thing for web users, they just: click, , click, , ... so we can allow them to exceed their bw for few seconds, just to load typical webpage. . bigger burst may be a good thing when limiting per-user upstream usage on assymetric lines, e.g. on 128kbit/512kbit ADSL limit user so one is able to send 64kbit/s up, however, after sending more than x MBytes (e-mail with attachment) his speed will go down to 32kbit/s. regards, -- Paweł Małachowski