From owner-freebsd-ipfw@FreeBSD.ORG Fri May 23 08:05:27 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 4F21537B405 for ; Fri, 23 May 2003 08:05:27 -0700 (PDT) Received: from epita.fr (hermes.epita.fr [163.5.255.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C13B43FB1 for ; Fri, 23 May 2003 08:05:26 -0700 (PDT) (envelope-from le-hen_j@epita.fr) Received: from carpediem (carpediem.epita.fr [10.42.42.5]) by epita.fr id h4NF5Iq15237 Fri, 23 May 2003 17:05:18 +0200 (MEST) Date: Fri, 23 May 2003 17:05:18 +0200 From: jeremie le-hen To: Michael Sierchio Message-ID: <20030523150517.GC24992@carpediem.epita.fr> References: <20030523105030.GA24992@carpediem.epita.fr> <3ECE21BD.7060308@tenebras.com> <20030523140140.GB24992@carpediem.epita.fr> <3ECE2D09.70609@tenebras.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3ECE2D09.70609@tenebras.com> User-Agent: Mutt/1.4i 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 15:05:27 -0000 > Ah, you're adjusting the camel from the wrong end. ;-) > > It's not queue size you want to adjust. If you want to reduce > delays for interactive traffic (telnet? ssh? etc.) assign that > traffic to a different queue, and all the queues to the same pipe. > Then you get the promised "worst case weighted fair queueing" In fact, I already have some queues in order to improve delays for interactive traffic. Here they are: pipe 1 config bw 125Kbit/s queue 76KBytes queue 10 config weight 100 pipe 1 mask all queue 20 config weight 100 pipe 1 queue 30 config weight 50 pipe 1 queue 40 config weight 1 pipe 1 # IRC, FTP, ICQ add queue 10 tcp from any to any 6667,5190,21 out via tun0 # SSH small packets (not file transfert via scp) add queue 10 tcp from any to any 22 iplen 1-1000 out via tun0 add queue 10 tcp from any 22 to any iplen 1-1000 out via tun0 # small ICMP, DNS requests and identd replies add queue 10 icmp from any to any iplen 1-200 out via tun0 add queue 10 udp from any to any 53 out via tun0 add queue 10 tcp from any 113 to any out via tun0 # TCP small packets (including SYNs, ACKs) add queue 20 tcp from any to any iplen 1-60 out via tun0 # SSH big packets (scp / rsync) add queue 40 tcp from any to any 22 iplen 1001-1500 out via tun0 add queue 40 tcp from any 22 to any iplen 1001-1500 out via tun0 # everything else add queue 30 tcp from any to any out via tun0 This just works fine, compared to when I didn't have any traffic shapping enabled. But I wanted to improve the responsivness of interactive traffic more and more, so I got concerned with queue size for the main pipe. > Once you've done this, then you might consider decreasing the > queue size on the interactive traffic. If it's full, it will > get priority. I'd think in terms of numbers of packets rather > than octets, probably... 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 ? Finally, I should reduce size of interactive traffic queues, and increase size of the others. But how much ? Regards, -- Jeremie aka TtZ/TataZ jeremie.le-hen@epita.fr