From owner-freebsd-net@FreeBSD.ORG Tue Oct 6 09:34:37 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 AC6E9106568D for ; Tue, 6 Oct 2009 09:34:37 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx75.mail.ru (mx75.mail.ru [94.100.176.90]) by mx1.freebsd.org (Postfix) with ESMTP id 653048FC14 for ; Tue, 6 Oct 2009 09:34:37 +0000 (UTC) Received: from [217.25.27.27] (port=2945 helo=[217.25.27.27]) by mx75.mail.ru with asmtp id 1Mv6RH-000IeR-00; Tue, 06 Oct 2009 13:34:35 +0400 Message-ID: <4ACB0F28.3000906@mail.ru> Date: Tue, 06 Oct 2009 14:34:32 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Luigi Rizzo References: <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <20091005120418.GA63131@onelab2.iet.unipi.it> <4AC9E29B.6080908@mail.ru> <20091005123230.GA64167@onelab2.iet.unipi.it> <4AC9EFDF.4080302@mail.ru> <4ACA2CC6.70201@elischer.org> <4ACAFF2A.1000206@mail.ru> <4ACB0C22.4000008@mail.ru> <20091006093408.GA86830@onelab2.iet.unipi.it> In-Reply-To: <20091006093408.GA86830@onelab2.iet.unipi.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam: Not detected X-Mras: Ok Cc: freebsd-net@freebsd.org, Julian Elischer 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: Tue, 06 Oct 2009 09:34:37 -0000 Luigi Rizzo wrote: > On Tue, Oct 06, 2009 at 02:21:38PM +0500, rihad wrote: >> rihad wrote: >>> Julian Elischer wrote: >>>> rihad wrote: >>>>> Luigi Rizzo wrote: >>>>>> 2. your test with 'ipfw allow ip from any to any' does not >>>>>> prove that the interface queue is not saturating, because >>>>>> you also remove the burstiness that dummynet introduces, >>>>>> and so the queue is driven differently. >>>>>> >>>>> How do I investigate and fix this burstiness issue? >>>> higher Hz rate? >>>> >>> Rebooted with HZ=2000 10 minutes ago. Due to application design the ipfw >>> table (pipe tablearg) was flushed, so there are now 350 (and increasing >>> at a rate 1 per 1-2 seconds as I type this) or so users in the table, >>> and not 4k as normally would be. The box is servicing 450+ mbit/s >>> without a single drop. I want to monitor how things change once the >>> number of users in ipfw tables gradually increases up to several thousands. >>> >> It starts dropping packets at around 2000 online users (ipfw table >> load). I've set up a shell script to monitor this: > > once again: > you should check which pipes are dropping packets and whether > the number of drops indicated in the pipes matches the counts > indicated by netstat. > It's impossible to do so accurately, since users come and go any moment, and their pipes expire, and it's plain useless. As to the accordance of packet drop rate with net.inet.ip.dummynet.io_pkt_drop, they vary wildly: 8664 output packets dropped due to no bufs, etc. net.inet.ip.dummynet.io_pkt_drop: 111 since boottime!