From owner-freebsd-net@FreeBSD.ORG Mon Oct 5 17:33:44 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 997CD1065672 for ; Mon, 5 Oct 2009 17:33:44 +0000 (UTC) (envelope-from rihad@mail.ru) Received: from mx38.mail.ru (mx38.mail.ru [94.100.176.52]) by mx1.freebsd.org (Postfix) with ESMTP id 51C5A8FC19 for ; Mon, 5 Oct 2009 17:33:44 +0000 (UTC) Received: from [217.25.27.27] (port=56179 helo=[217.25.27.27]) by mx38.mail.ru with asmtp id 1MurRO-000Gan-00; Mon, 05 Oct 2009 21:33:42 +0400 Message-ID: <4ACA2DDB.50809@mail.ru> Date: Mon, 05 Oct 2009 22:33:15 +0500 From: rihad User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090706) MIME-Version: 1.0 To: Julian Elischer 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> <4AC9CFF7.3090208@mail.ru> <20091005110726.GA62598@onelab2.iet.unipi.it> <4AC9D87E.7000005@mail.ru> <4ACA2A52.4050704@elischer.org> In-Reply-To: <4ACA2A52.4050704@elischer.org> 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, Luigi Rizzo 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 17:33:44 -0000 Julian Elischer wrote: > rihad wrote: >> Luigi Rizzo wrote: >>> On Mon, Oct 05, 2009 at 03:52:39PM +0500, rihad wrote: >>>> Eugene Grosbein wrote: >>>>> On Mon, Oct 05, 2009 at 02:28:58PM +0500, rihad wrote: >>>>> >>>>>> 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. >>>>> >>>> Alright, so I changed to gred by adding to each config command: >>>> ipfw ... gred 0.002/900/1000/0.1 queue 1000 >>>> and reconfigured. Still around 300-400 drops per second, which was >>>> typical at this load level before with taildrop anyway. There are >>>> around 3-5 mbit/s being wasted according to systat -ifstat. >>>> >>>> Should I now increase slots to 5-10-20k? >>>> Very strange. >>>> >>>> "ipfw pipe show" correctly shows that gred is at work. For example: >>>> 00512: 512.000 Kbit/s 0 ms 1000 sl. 79 queues (64 buckets) >>>> GRED w_q 0.001999 min_th 900 max_th 1000 max_p 0.099991 >>>> mask: 0x00 0x00000000/0x0000 -> 0xffffffff/0x0000 >>>> ... >>> >>> you keep omitting the important info i.e. whether individual >>> pipes have drops, significant queue lenghts and so on. >>> >> Sorry. Almost everyone has 0 in the last Drp column, but some have >> above zero. I'm not just sure how this can be helpful to anyone. > > > This tells us there are just a few sessions with VERY LARGE WINDOWS > that are trying to push the link too fast. They are flooding the > firewall and geting all the drops. (unless the problem is that the > hash/mask is putting a lot of session on the same slot.) > > All masks are dst-ip 0xffffffff. I doubt very strongly that it's due to such offenders, because all the way from 4a.m. to 10a.m. at the load of 200-330 mbit/s there are zero drops. There are no doubt heavy downloaders leaving their PCs on in the night. The drops begin as soon as the load crosses 340-360 mbit/s or some such, and it only worsens as the load approaches 500-530 mbit/s.