From owner-freebsd-net@FreeBSD.ORG Mon Oct 5 09:58:07 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 295AE1065672 for ; Mon, 5 Oct 2009 09:58:07 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E09138FC21 for ; Mon, 5 Oct 2009 09:58:06 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 2390B730DA; Mon, 5 Oct 2009 12:04:46 +0200 (CEST) Date: Mon, 5 Oct 2009 12:04:46 +0200 From: Luigi Rizzo To: Eugene Grosbein Message-ID: <20091005100446.GA60244@onelab2.iet.unipi.it> References: <4AC8A76B.3050502@mail.ru> <20091005025521.GA52702@svzserv.kemerovo.su> <20091005061025.GB55845@onelab2.iet.unipi.it> <4AC9B400.9020400@mail.ru> <20091005090102.GA70430@svzserv.kemerovo.su> <4AC9BC5A.50902@mail.ru> <20091005095600.GA73335@svzserv.kemerovo.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20091005095600.GA73335@svzserv.kemerovo.su> User-Agent: Mutt/1.4.2.3i Cc: rihad , freebsd-net@freebsd.org Subject: Re: dummynet dropping too many packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2009 09:58:07 -0000 On Mon, Oct 05, 2009 at 05:56:00PM +0800, Eugene Grosbein wrote: > On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote: > > > Oh, I almost forgot... Right now I've googled up and am reading this > > intro: http://www-rp.lip6.fr/~sf/WebSF/PapersWeb/iscc01.ps > > > > So turning to GRED would turn my FreeBSD router from dumb into a smart > > router that knows TCP? I thought pushing bits around at a lower level, > > and a sufficient queue size were enough. > > No, it will still deal with IP packets but more clever. > > > Still not sure why increasing queue size as high as I want doesn't > > completely eliminate drops. > > The goal is to make sources of traffic to slow down, this is the only > way to descrease drops - any finite queue may be overhelmed with traffic. > Taildrop does not really help with this. GRED does much better. i think the first problem here is figure out _why_ we have the drops, as the original poster said that queues are configured with a very large amount of buffer (and i think there is a misconfiguration somewhere because the mbuf stats do not make sense) cheers luigi