From owner-freebsd-stable@FreeBSD.ORG Sat May 26 00:32:30 2007 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4F8DE16A421 for ; Sat, 26 May 2007 00:32:30 +0000 (UTC) (envelope-from security@jim-liesl.org) Received: from qsmtp3.mc.surewest.net (qsmtp.mc.surewest.net [66.60.130.145]) by mx1.freebsd.org (Postfix) with SMTP id 33ABC13C468 for ; Sat, 26 May 2007 00:32:29 +0000 (UTC) (envelope-from security@jim-liesl.org) Received: (qmail 13175 invoked from network); 25 May 2007 17:05:48 -0700 Received: by simscan 1.1.0 ppid: 13160, pid: 13161, t: 4.6515s scanners: regex: 1.1.0 attach: 1.1.0 clamav: 0.84/m:43/d:3122 spam: 3.0.3 Received: from unknown (HELO daemon.jim-liesl.org) (66.60.173.44) by qsmtp3 with SMTP; 25 May 2007 17:05:44 -0700 Received: from daemon.jim-liesl.org (localhost.static.surewest.net [127.0.0.1]) by daemon.jim-liesl.org (Postfix) with ESMTP id 198B65C1D; Fri, 25 May 2007 17:05:44 -0700 (PDT) Received: from [127.0.0.1] (daemon.static.surewest.net [192.168.1.15]) by daemon.jim-liesl.org (Postfix) with ESMTP id C79E55C1C; Fri, 25 May 2007 17:05:43 -0700 (PDT) Message-ID: <465779D7.6030502@jim-liesl.org> Date: Fri, 25 May 2007 17:05:43 -0700 From: security User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Stephen.Clark@seclark.us References: <4656D0FB.5070200@seclark.us> In-Reply-To: <4656D0FB.5070200@seclark.us> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on qsmtp3.surewest.net X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.3 Cc: freebsd-stable@freebsd.org Subject: Re: network performance 6.1 stable vs 4.9 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2007 00:32:30 -0000 Stephen Clark wrote: > Hello List, > > We have a network appliance that is currently based on 4.9. We are in > the process of releasing > a new version based on 6.1 stable. > > In our testing using nttcp thru the appliance we see insignifant > difference in thruput between the 2 > versions in a controlled environment - aproximately 94mbs on a 100mb lan. > > We have a person that is testing the both system inhouse surfing out > over the internet on our T1 > link and he complains that he is consistently seeing the 6.1 version > being much slower than the > 4.9 version (on the same hardware). > He has been comparing the 6.1 system to 4.9 system for a couple of weeks > and continues to insist the 6.1 version is much slower. > > Are there any sysctl tunables that may affect performance going over > the internet > with a slower link, dropped packets, etc that could cause this? > Well, oddly enough I've playing with 6.1's perf as it relates to gigE lans so let me pass on a few things * polling only really helps if your nic is generating lot's of interrupts, or is having to compete with something that does. In fact, setting "polling" on an interface could make things seem slightly LESS responsive for small requests * nic chipset selection is important, but probably not for a f/w dealing with t1/broadband speeds * Don't even get down tweaking tcp send and recv buffers. You have no idea what the BDP will be on your WAN link. Same thing for jumbo frames on the inside link. o Having said that, This is what is in my sysctl.conf file. It does matter in a gigE lan, but probably not for a SMB firewall thats only got a t1 on the WAN side. kern.ipc.maxsockbuf=8192000 net.inet.tcp.sendspace=262144 net.inet.tcp.recvspace=262144 * make sure you set net.inet.tcp.rfc1323: 1 (most likely the default) * play with net.inet.tcp.inflight.enable (0 or 1), it never made a diff in my gigE lan testing * get real data using iperf (in ports/benchmarking) if you go to the iperf website, they have binaries for windows o XP's default network tuning is beyond bad, but your customers most likely aren't tweaking their registries either * use netstat -m to look at your buffer usage, particularly if you're dropping packets * depending on how much memory you have you might want to jump up kern.ipc.nmbclusters, but only if you seem to be dropping packets. * verify that your nics are setting speed and duplex correctly * which firewall package are you using? * use ethereal/wireshark to examine your net flow. Alot of tcp resets and retransmits can make a big impact if TCP is constantly having to resync. jim