From owner-freebsd-performance@FreeBSD.ORG Thu Feb 15 21:57:30 2007 Return-Path: X-Original-To: freebsd-performance@freebsd.org Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AD47E16A401 for ; Thu, 15 Feb 2007 21:57:30 +0000 (UTC) (envelope-from fcash@ocis.net) Received: from smtp.sd73.bc.ca (smtp.sd73.bc.ca [142.24.13.140]) by mx1.freebsd.org (Postfix) with ESMTP id 907EC13C442 for ; Thu, 15 Feb 2007 21:57:30 +0000 (UTC) (envelope-from fcash@ocis.net) Received: from localhost (localhost [127.0.0.1]) by localhost.sd73.bc.ca (Postfix) with ESMTP id AC17C1A000B0C for ; Thu, 15 Feb 2007 13:57:29 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at smtp.sd73.bc.ca Received: from smtp.sd73.bc.ca ([127.0.0.1]) by localhost (smtp.sd73.bc.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id M3bl41BFycoB for ; Thu, 15 Feb 2007 13:57:23 -0800 (PST) Received: from coal (s10.sbo [192.168.0.10]) by smtp.sd73.bc.ca (Postfix) with ESMTP id 1667E1A000B0F for ; Thu, 15 Feb 2007 13:57:23 -0800 (PST) From: Freddie Cash To: freebsd-performance@freebsd.org Date: Thu, 15 Feb 2007 13:57:21 -0800 User-Agent: KMail/1.9.5 References: <20070207120426.CDEFC16A407@hub.freebsd.org> <200702151211.45177.fcash@ocis.net> <45D4D0D1.5020902@sk1llz.net> In-Reply-To: <45D4D0D1.5020902@sk1llz.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702151357.22075.fcash@ocis.net> Subject: Re: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Feb 2007 21:57:30 -0000 On Thursday 15 February 2007 01:29 pm, Justin Robertson wrote: > Send a flood of 60 byte syn packets with the tcp sack option thru > it and check out what happens. It's pretty weird and I can't explain > why. If you block the packets on the box via ipfw it's fine, the second > it has to make a routing decision everything goes out the window, it > seems. There's 100% packet loss on all protocols. I'm not using NAT, > there are real IPs in different C classes on the other side of the box. Is that something that would occur normally? Or is this a worst-case/stress-test trying to break things? How are you generating the packets? I'm not a network guru, and haven't done much in the way of network-related stress-testing, but I'm always looking for ways to do so. -- Freddie Cash fcash@ocis.net