From owner-freebsd-net@FreeBSD.ORG Mon Oct 19 17:45:08 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 1DE72106566C; Mon, 19 Oct 2009 17:45:08 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx34.mail.ru (mx34.mail.ru [94.100.176.48]) by mx1.freebsd.org (Postfix) with ESMTP id CA37C8FC1A; Mon, 19 Oct 2009 17:45:07 +0000 (UTC) Received: from [217.25.27.27] (port=60365 helo=[217.25.27.27]) by mx34.mail.ru with asmtp id 1MzwI0-0001ak-00; Mon, 19 Oct 2009 21:45:01 +0400 Message-ID: <4ADCA59C.3090601@mail.ru> Date: Mon, 19 Oct 2009 22:45:00 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Oleg Bulyzhin References: <20091007085902.GA88982@lath.rinet.ru> <4ACC5E23.8090405@mail.ru> <20091007100503.GB88982@lath.rinet.ru> <4ACC6A7B.5050808@mail.ru> <20091007104525.GC88982@lath.rinet.ru> <4ACC7308.6070301@mail.ru> <4ACCC30E.7080504@elischer.org> <4ACCC4F3.3030302@mail.ru> <20091008060608.GA23793@lath.rinet.ru> <4ACE10CF.2030806@elischer.org> <20091009082743.GB70940@lath.rinet.ru> In-Reply-To: <20091009082743.GB70940@lath.rinet.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: 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, 19 Oct 2009 17:45:08 -0000 Oleg Bulyzhin wrote: > One more idea to check: > > What happens if you rearrange your rules to shape 'in' packets? > i.e. use 'in recv bce0' instead of 'out recv bce0 xmit bce1'. Wow, shape incoming packets? That's a good one - the packets could still buffer up waiting to be output. I'm not sure this will eliminate burstiness (if it IS the problem), but I'll no doubt try this if current changes don't prove to be helpful. Currently we've been running running a "ifq_drv_maxlen = 4096;" kernel with HZ=4000 for a few hours, 0 drops so far with around 2700 entries in each of the two IPFW tables (no big surprise so far, we had this with maxlen=1024 too with under 3000 entries).