From owner-freebsd-ipfw@FreeBSD.ORG Fri May 23 10:06:00 2003 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 7333E37B404 for ; Fri, 23 May 2003 10:06:00 -0700 (PDT) Received: from laptop.tenebras.com (laptop.tenebras.com [66.92.188.18]) by mx1.FreeBSD.org (Postfix) with SMTP id C192A43FA3 for ; Fri, 23 May 2003 10:05:59 -0700 (PDT) (envelope-from kudzu@tenebras.com) Received: (qmail 43314 invoked from network); 23 May 2003 17:05:58 -0000 Received: from queequeg.tenebras.com (HELO tenebras.com) (192.168.188.241) by 0 with SMTP; 23 May 2003 17:05:58 -0000 Message-ID: <3ECE54F5.3000301@tenebras.com> Date: Fri, 23 May 2003 10:05:57 -0700 From: Michael Sierchio User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en, zh-cn, zh-tw MIME-Version: 1.0 To: jeremie le-hen References: <20030523105030.GA24992@carpediem.epita.fr> <3ECE21BD.7060308@tenebras.com> <20030523140140.GB24992@carpediem.epita.fr> <3ECE2D09.70609@tenebras.com> <20030523150517.GC24992@carpediem.epita.fr> In-Reply-To: <20030523150517.GC24992@carpediem.epita.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: ipfw@freebsd.org Subject: Re: Understanding queue size X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2003 17:06:00 -0000 jeremie le-hen wrote: > I hadn't understood I had to play with queue size for each queues, and not > with the one of the main pipe. But that's the key ! :) > > Does reducing or increasing queue size of the main pipe have any relevance ? You should have pipes for incoming and outgoing traffic that are large enough (in terms of bw) for the burst/connect rate of your connection. Other than that, you may assign multiple queues to that pipe, and bandwidth will be allocated fairly among them based on their weights. > Finally, I should reduce size of interactive traffic queues, and increase > size of the others. But how much ? I'm not sure that this is really what you want to do... interactive latency starts getting to be perceptible at 0.125s and annoying at 0.5s, but this depends on MTU size and other things as well. One way of preventing a nearby or high-powered host from hogging all the bandwidth (that power user with the dual 2.8GHz desktop machine who's downloading mp3s all day) is to use RED or GRED. Do some reading on it before asking how to set the parameters, it's not an exact science. That being said, make the queue size the equivalent to the tolerable delay for interactive processes. You might consider using masks on the interactive queues, since interactive sessions can easily become bulk data transfer sessions (an ssh tunnel). And rememember: il faut garder quelques sourires pour se moquer des jours sans joie.