From owner-freebsd-performance@FreeBSD.ORG Mon Feb 5 11:39:52 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 5EDA516A494 for ; Mon, 5 Feb 2007 11:39:46 +0000 (UTC) (envelope-from garcol@postino.it) Received: from abraham.elitel.it (vdisk2.elitel.it [212.34.224.151]) by mx1.freebsd.org (Postfix) with SMTP id C2F9013C4B3 for ; Mon, 5 Feb 2007 11:39:44 +0000 (UTC) (envelope-from garcol@postino.it) Received: (qmail 24868 invoked by uid 65534); 5 Feb 2007 11:39:23 -0000 X-Spam-Checker-Version: SpamAssassin on abraham.elitel.it X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.2 tests=BAYES_00,NO_REAL_NAME autolearn=no Received: from 212.63.96.97 ([212.63.96.97]) by www.postino.punto.it (IMP) with HTTP for ; Mon, 5 Feb 2007 12:39:23 +0100 Message-ID: <1170675563.45c7176b1ce0b@www.postino.punto.it> Date: Mon, 5 Feb 2007 12:39:23 +0100 From: garcol@postino.it To: "freebsd-performance@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 212.63.96.97 Subject: PHP Performance problem after upgrade to 5.1.6 or 5.2.0 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: Mon, 05 Feb 2007 11:39:52 -0000 Hi, > * Miroslav Lachman (000.fbsd at quip.cz) wrote: > > >>I have performance problem with PHP after upgrading from PHP 5.1.4 to >>newer version regardles if newer version is 5.1.6 or 5.2.0. I tested >>both with same result. > > > Every time I upgrade PHP and see a performace regregression like this, > it's been a result of forgetting to update eAccelerator, or whatever > flavour of the year PHP bytecode cache is at the time. > > If you're sure your cache is loading (i.e. it shows up in phpinfo() > and isn't logging errors on startup), you might find it useful to grab > backtraces from busy processes (the source tarball includes a .gdbinit > that allows you to grab PHP backtraces too, provided you're compiling > with debug symbols enabled) to see where they might be spending their > time. I am not using any PHP bytecode cache. About one year ago I tried eAccelerator which causes Apache freeze. Now I installed ZendOptimizer and load increased!! by 50% :o( -- Miroslav Lachman The upgrade from 5.1x to 5.2x make same change into memory utilizzation (ex. Zend memory manager) and apache2 SAPI. (try to check the apache memory utilizzation) You can check the php-5.2.0 changelog to find out some important change for yours applications (no fixed bug) or retry with new version of php. Alessandro From owner-freebsd-performance@FreeBSD.ORG Tue Feb 6 15:35:21 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 D22A416A400 for ; Tue, 6 Feb 2007 15:35:21 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9132B13C4A6 for ; Tue, 6 Feb 2007 15:35:21 +0000 (UTC) (envelope-from gofp-freebsd-performance@m.gmane.org) Received: from root by ciao.gmane.org with local (Exim 4.43) id 1HESLX-0002BW-Uv for freebsd-performance@freebsd.org; Tue, 06 Feb 2007 16:35:04 +0100 Received: from brist1-dhcp-31.greenmountainaccess.net ([69.54.15.31]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Feb 2007 16:35:03 +0100 Received: from scott by brist1-dhcp-31.greenmountainaccess.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 06 Feb 2007 16:35:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-performance@freebsd.org From: "Scott I. Remick" Date: Tue, 6 Feb 2007 15:29:19 +0000 (UTC) Lines: 8 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: brist1-dhcp-31.greenmountainaccess.net X-Archive: encrypt User-Agent: pan 0.121 (Dortmunder) Sender: news X-Mailman-Approved-At: Tue, 06 Feb 2007 16:02:24 +0000 Subject: WHT thread: FreeBSD vs. CentOS 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: Tue, 06 Feb 2007 15:35:21 -0000 Just wanted to give those on the list a heads-up about this thread over on WebHostingTalk: http://www.webhostingtalk.com/showthread.php?t=563624 It's been going on a few months now. Apparently a number of webhosts are finding poor FreeBSD performance when compared with CentOS. Perhaps someone on here would like to pipe in with some assistance? From owner-freebsd-performance@FreeBSD.ORG Wed Feb 7 09:48:07 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 BC05E16A4A0 for ; Wed, 7 Feb 2007 09:48:07 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: from sed.awknet.com (sed.awknet.com [66.152.175.11]) by mx1.freebsd.org (Postfix) with ESMTP id 95DCB13C491 for ; Wed, 7 Feb 2007 09:48:07 +0000 (UTC) (envelope-from justin@sk1llz.net) Received: by sed.awknet.com (Postfix, from userid 58) id 8597410BBE55; Wed, 7 Feb 2007 01:37:02 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on sed.awknet.com X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=AWL,BAYES_50 autolearn=disabled version=3.1.3 Received: from [192.168.1.101] (cpe-76-167-105-254.socal.res.rr.com [76.167.105.254]) by sed.awknet.com (Postfix) with ESMTP id CE0DF10BBCF9 for ; Wed, 7 Feb 2007 01:37:00 -0800 (PST) Message-ID: <45C99DBC.1050402@sk1llz.net> Date: Wed, 07 Feb 2007 01:37:00 -0800 From: Justin Robertson User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-performance@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 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: Wed, 07 Feb 2007 09:48:07 -0000 It was suggested I post this to freebsd-performance, it's already in questions, isp, and net. I've been running some tests with using FreeBSD to filter and rate limit traffic. My first thoughts were to goto the latest stable release, which was 6.1 at the time. I've since done the same test under 6.2 and haven't seen any difference. I later migrated to running 4.11 to get away from these issues, but have discovered others. I've tested on an AMD 3200+ system with dual Intel 1000 series NICs, an AMD Opteron 165 with the same, and a Xeon 2.8 with the same. I've used both stock and intel drivers. 6.x; Normal traffic isn't a problem. The second you get into the realm of abusive traffic, such a DoS/DDoS (over 100mbps) UDP floods the machine falls over. Little packets with ip lengths of 28-29 bytes seem to do the most damage. I've tried playing with various sysctl values and have seen no difference at all. By "falls over" I mean "stops sending all traffic in any direction". TCP syn packets have the same effect, tho not quite as rapidly (200~230mbps). I then tried moving filtering off to a transparent bridge. This improved the situation somewhat, but an extra 30-40mbps of UDP data and it would ultimately crumble. Overall the machine would be able to move between 300k-600k PPS before becoming a cripple, depending on packet length, protocol, and any flags. Without a specific pf or ipfw rule to deal with a packet the box would fall over, with specific block rules it would manage an extra 30-40mbps and then fall over. 4.11; Again, normal traffic isn't a problem. When routing & filtering on the same system some of the problems found in 6.x are still apparent, but to a lesser degree. Splitting the task into a transparent filtering bridge with a separate routing box appears to clear it up entirely. UDP floods are much better handled - an ipfw block rule for the packet type and the machine responds as if there were no flood at all (until total bandwidth saturation or PPS limits of the hardware, which in this case was around 950Mbps). TCP syn attacks are also better handled, again a block rule makes it seem as if there were no attack at all. The system also appears to be able to move 800-900k PPS of any one protocol at a time. However, the second you try and queue abusive traffic the machine will fall over. Inbound floods appear to cause ALL inbound traffic to lag horrifically (while rate limiting/piping), which inherently causes a lot of outbound loss due to broken TCP. Now, I'm not sure if this is something to do with dummynet being horribly inefficient, or if there's some sysctl value to deal with inbound that I'm missing. I suppose my concerns are two-fold. Why is 6.x collapsing under traffic that 4.11 could easily block and run merrily along with, and is there a queueing mechanism in place that doesn't tie up the box so much on inbound flows that it ignores all other relevant traffic? (as a note, all tests were done with device polling enabled. Without it systems fall over pretty quickly. I also tried tests using 3com cards and had the same results) In the event anybody is looking for basic errors, device polling is enabled and running at 4000 hz, which has proved to net the highest thruput in PPS. ADAPTIVE_GIANT is on (tests resulted in better pps thruput), all the other monitoring features are disabled, and here are my sysctl modifications related to networking (if there's something glaring let me know!); kern.polling.enable=1 kern.polling.burst_max=1000 kern.polling.each_burst=80 kern.polling.idle_poll=1 kern.polling.user_frac=20 kern.polling.reg_frac=50 net.inet.tcp.recvspace=262144 net.inet.tcp.sendspace=262144 kern.ipc.maxsockbuf=1048576 net.inet.tcp.always_keepalive=1 net.inet.ip.portrange.first=10000 kern.ipc.somaxconn=65535 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 net.inet.icmp.icmplim=30 net.inet.ip.forwarding=1 net.inet.ip.portrange.randomized=0 net.inet.udp.checksum=0 net.inet.udp.recvspace=8192 (I've tried large and small, thinking perhaps I was fulling up buffers on udp floods and then causing it to drop tcp, there appears to be no difference) net.inet.ip.intr_queue_maxlen=512 net.inet.tcp.delayed_ack=0 net.inet.tcp.rfc1323=1 net.inet.tcp.newreno=0 (I'd try this, but, the biggest problem is still with UDP, and I'd prefer something compatible with everything for now) net.inet.tcp.delacktime=10 net.inet.tcp.msl=2500 net.inet.ip.rtmaxcache=1024 net.inet.raw.recvspace=262144 net.inet.ip.dummynet.hash_size=512 net.inet.ip.fw.dyn_ack_lifetime=30 net.inet.ip.fw.dyn_syn_lifetime=10 net.inet.ip.fw.dyn_fin_lifetime=10 net.inet.ip.fw.dyn_max=16192 net.link.ether.bridge.enable=0 (or 1 on when setup to bridge, obviously) net.inet.ip.fastforwarding=1 It has also been pointed out that using net.link.ether.ipfw=1 should negate the need for a transparent box, however the performance disparity between 6.x and 4.11 remains. From owner-freebsd-performance@FreeBSD.ORG Thu Feb 8 03:34:11 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 64D9A16A400 for ; Thu, 8 Feb 2007 03:34:09 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.freebsd.org (Postfix) with ESMTP id 3B93C13C4AA for ; Thu, 8 Feb 2007 03:34:09 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 0879C4D7CF for ; Thu, 8 Feb 2007 03:22:27 +0000 (GMT) Received: from smitch7.jumbuck.com (unknown [206.112.99.82]) by p4.roq.com (Postfix) with ESMTP id D38FA4D4A2 for ; Thu, 8 Feb 2007 03:22:26 +0000 (GMT) Received: from smitch7.jumbuck.com (mail.jumbuck.com [206.112.99.82]) by smitch7.jumbuck.com (Postfix) with ESMTP id 2D0444111CB; Thu, 8 Feb 2007 03:18:58 +0000 (UTC) Received: from beaste5.jumbuck.com (melbourne.jumbuck.com [150.101.166.27]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by smitch7.jumbuck.com (Postfix) with ESMTP id D11D8410EA6; Thu, 8 Feb 2007 03:18:57 +0000 (UTC) Received: from beaste5.jumbuck.com (beast5 [192.168.46.105]) by beaste5.jumbuck.com (Postfix) with ESMTP id B54B5209D1A9; Thu, 8 Feb 2007 14:18:56 +1100 (EST) Received: from [192.168.46.102] (unknown [192.168.46.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by beaste5.jumbuck.com (Postfix) with ESMTP id 8E106209D195; Thu, 8 Feb 2007 14:18:56 +1100 (EST) Message-ID: <45CA96A0.7070404@thebeastie.org> Date: Thu, 08 Feb 2007 14:18:56 +1100 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.13) Gecko/20060727 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Scott I. Remick" References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-performance@freebsd.org Subject: Re: WHT thread: FreeBSD vs. CentOS 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, 08 Feb 2007 03:34:11 -0000 Scott I. Remick wrote: >Just wanted to give those on the list a heads-up about this thread over on >WebHostingTalk: > >http://www.webhostingtalk.com/showthread.php?t=563624 > >It's been going on a few months now. Apparently a number of webhosts are >finding poor FreeBSD performance when compared with CentOS. Perhaps >someone on here would like to pipe in with some assistance? > > > This filesystem benchmark for his particular raid card seems a bit silly to judge the whole OS on. It could simply be that the driver for that particular raid card wasn't as well coded/tuned for performance for FreeBSD as the linux version, you can't judge a whole OS on that for the most part his server hardware seems a bit rare and weird. That score on linux is not much more then 10% higher, I mean if 10% makes all the difference between all the possible advantages you can get or not get on a particular OS I think its just thinking a bit too square, this seems to be a bit of a epidemic way of thinking. Its the same was of thinking when I see benchmarking with MySQL people can spot a difference between Linux and FreeBSD of up to 30%? when doing 100,000 threads of queries at the same time, when most MySQL databases are doing around 20 threads? And in more higher cases maybe 500 threads at the same time max, in this ball park its impossible to see a difference between OS/MySQL performance. For judging a OS on a particular performance of a particular raid card driver is part of the same group of thinking. It would be nice in the future if people judge a OS with a wider range of factors. Mike From owner-freebsd-performance@FreeBSD.ORG Thu Feb 8 10:19:21 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 032FA16A485 for ; Thu, 8 Feb 2007 10:19:18 +0000 (UTC) (envelope-from garcol@postino.it) Received: from abraham.elitel.it (vdisk2.elitel.it [212.34.224.151]) by mx1.freebsd.org (Postfix) with SMTP id 4E55213C4A3 for ; Thu, 8 Feb 2007 10:19:09 +0000 (UTC) (envelope-from garcol@postino.it) Received: (qmail 21384 invoked by uid 65534); 8 Feb 2007 10:18:48 -0000 X-Spam-Checker-Version: SpamAssassin on abraham.elitel.it X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.2 tests=BAYES_00,NO_REAL_NAME autolearn=no Received: from 212.63.96.97 ([212.63.96.97]) by www.postino.punto.it (IMP) with HTTP for ; Thu, 8 Feb 2007 11:18:47 +0100 Message-ID: <1170929927.45caf9080183d@www.postino.punto.it> Date: Thu, 8 Feb 2007 11:18:48 +0100 From: garcol@postino.it To: freebsd-performance@freebsd.org References: <20070207120426.CDEFC16A407@hub.freebsd.org> In-Reply-To: <20070207120426.CDEFC16A407@hub.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.2 X-Originating-IP: 212.63.96.97 Subject: 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, 08 Feb 2007 10:19:21 -0000 Hi, I think you can try to check/tuning this sysctl variables and the isr related variables: net.inet.ip.intr_queue_maxlen net.inet.ip.intr_queue_drops net.isr.enable ... try to set net.isr.directed net.isr.queued net.isr.drop and polling configuration: kern.clockrate kern.polling.burst_max .... increase for high rate of small packets on GE .... Alessandro > Date: Wed, 07 Feb 2007 01:37:00 -0800 > From: Justin Robertson > Subject: 6.x, 4.x ipfw/dummynet pf/altq - network performance issues > To: freebsd-performance@freebsd.org > Message-ID: <45C99DBC.1050402@sk1llz.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > It was suggested I post this to freebsd-performance, it's already in > questions, isp, and net. > > I've been running some tests with using FreeBSD to filter and rate limit > traffic. My first thoughts were to goto the latest stable release, which > was 6.1 at the time. I've since done the same test under 6.2 and haven't > seen any difference. I later migrated to running 4.11 to get away from > these issues, but have discovered others. > > I've tested on an AMD 3200+ system with dual Intel 1000 series NICs, an > AMD Opteron 165 with the same, and a Xeon 2.8 with the same. I've used > both stock and intel drivers. > > 6.x; > Normal traffic isn't a problem. The second you get into the realm of > abusive traffic, such a DoS/DDoS (over 100mbps) UDP floods the machine > falls over. Little packets with ip lengths of 28-29 bytes seem to do the > most damage. I've tried playing with various sysctl values and have seen > no difference at all. By "falls over" I mean "stops sending all traffic > in any direction". TCP syn packets have the same effect, tho not quite > as rapidly (200~230mbps). I then tried moving filtering off to a > transparent bridge. This improved the situation somewhat, but an extra > 30-40mbps of UDP data and it would ultimately crumble. Overall the > machine would be able to move between 300k-600k PPS before becoming a > cripple, depending on packet length, protocol, and any flags. Without a > specific pf or ipfw rule to deal with a packet the box would fall over, > with specific block rules it would manage an extra 30-40mbps and then > fall over. > > 4.11; > Again, normal traffic isn't a problem. When routing & filtering on the > same system some of the problems found in 6.x are still apparent, but to > a lesser degree. Splitting the task into a transparent filtering bridge > with a separate routing box appears to clear it up entirely. UDP floods > are much better handled - an ipfw block rule for the packet type and the > machine responds as if there were no flood at all (until total bandwidth > saturation or PPS limits of the hardware, which in this case was around > 950Mbps). TCP syn attacks are also better handled, again a block rule > makes it seem as if there were no attack at all. The system also appears > to be able to move 800-900k PPS of any one protocol at a time. However, > the second you try and queue abusive traffic the machine will fall over. > Inbound floods appear to cause ALL inbound traffic to lag horrifically > (while rate limiting/piping), which inherently causes a lot of outbound > loss due to broken TCP. Now, I'm not sure if this is something to do > with dummynet being horribly inefficient, or if there's some sysctl > value to deal with inbound that I'm missing. > > I suppose my concerns are two-fold. Why is 6.x collapsing under traffic > that 4.11 could easily block and run merrily along with, and is there a > queueing mechanism in place that doesn't tie up the box so much on > inbound flows that it ignores all other relevant traffic? > > (as a note, all tests were done with device polling enabled. Without it > systems fall over pretty quickly. I also tried tests using 3com cards > and had the same results) > > > In the event anybody is looking for basic errors, device polling is > enabled and running at 4000 hz, which has proved to net the highest > thruput in PPS. ADAPTIVE_GIANT is on (tests resulted in better pps > thruput), all the other monitoring features are disabled, and here are > my sysctl modifications related to networking (if there's something > glaring let me know!); > > kern.polling.enable=1 > kern.polling.burst_max=1000 > kern.polling.each_burst=80 > kern.polling.idle_poll=1 > kern.polling.user_frac=20 > kern.polling.reg_frac=50 > net.inet.tcp.recvspace=262144 > net.inet.tcp.sendspace=262144 > kern.ipc.maxsockbuf=1048576 > net.inet.tcp.always_keepalive=1 > net.inet.ip.portrange.first=10000 > kern.ipc.somaxconn=65535 > net.inet.tcp.blackhole=2 > net.inet.udp.blackhole=1 > net.inet.icmp.icmplim=30 > net.inet.ip.forwarding=1 > net.inet.ip.portrange.randomized=0 > net.inet.udp.checksum=0 > net.inet.udp.recvspace=8192 (I've tried large and small, thinking > perhaps I was fulling up buffers on udp floods and then causing it to > drop tcp, there appears to be no difference) > net.inet.ip.intr_queue_maxlen=512 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.rfc1323=1 > net.inet.tcp.newreno=0 (I'd try this, but, the biggest problem is still > with UDP, and I'd prefer something compatible with everything for now) > net.inet.tcp.delacktime=10 > net.inet.tcp.msl=2500 > net.inet.ip.rtmaxcache=1024 > net.inet.raw.recvspace=262144 > net.inet.ip.dummynet.hash_size=512 > net.inet.ip.fw.dyn_ack_lifetime=30 > net.inet.ip.fw.dyn_syn_lifetime=10 > net.inet.ip.fw.dyn_fin_lifetime=10 > net.inet.ip.fw.dyn_max=16192 > net.link.ether.bridge.enable=0 (or 1 on when setup to bridge, obviously) > net.inet.ip.fastforwarding=1 > > It has also been pointed out that using net.link.ether.ipfw=1 should > negate the need for a transparent box, however the performance disparity > between 6.x and 4.11 remains. > From owner-freebsd-performance@FreeBSD.ORG Sat Feb 10 15:29:50 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 7D0A816A402 for ; Sat, 10 Feb 2007 15:29:50 +0000 (UTC) (envelope-from lofi@freebsd.org) Received: from mail-in-12.arcor-online.net (mail-in-12.arcor-online.net [151.189.21.52]) by mx1.freebsd.org (Postfix) with ESMTP id E172113C491 for ; Sat, 10 Feb 2007 15:29:49 +0000 (UTC) (envelope-from lofi@freebsd.org) Received: from mail-in-01-z2.arcor-online.net (mail-in-07-z2.arcor-online.net [151.189.8.19]) by mail-in-12.arcor-online.net (Postfix) with ESMTP id 3A1A54CE48 for ; Sat, 10 Feb 2007 13:54:49 +0100 (CET) Received: from mail-in-01.arcor-online.net (mail-in-01.arcor-online.net [151.189.21.41]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id 2AAE12C6E2A for ; Sat, 10 Feb 2007 13:54:49 +0100 (CET) Received: from lofi.dyndns.org (dslb-084-061-173-053.pools.arcor-ip.net [84.61.173.53]) by mail-in-01.arcor-online.net (Postfix) with ESMTP id E62AB19B322 for ; Sat, 10 Feb 2007 13:54:48 +0100 (CET) Received: from kiste.my.domain (root@kiste.my.domain [192.168.8.2]) by lofi.dyndns.org (8.13.8/8.13.3) with ESMTP id l1ACsj37017396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 10 Feb 2007 13:54:45 +0100 (CET) (envelope-from lofi@freebsd.org) Received: from kiste.my.domain (lofi@localhost [127.0.0.1]) by kiste.my.domain (8.13.6/8.13.4) with ESMTP id l1ACsiNZ073431 for ; Sat, 10 Feb 2007 13:54:44 +0100 (CET) (envelope-from lofi@freebsd.org) Received: from localhost (localhost [[UNIX: localhost]]) by kiste.my.domain (8.13.6/8.13.4/Submit) id l1ACsi9G073430 for freebsd-performance@freebsd.org; Sat, 10 Feb 2007 13:54:44 +0100 (CET) (envelope-from lofi@freebsd.org) X-Authentication-Warning: kiste.my.domain: lofi set sender to lofi@freebsd.org using -f From: Michael Nottebrock To: freebsd-performance@freebsd.org Date: Sat, 10 Feb 2007 13:54:40 +0100 User-Agent: KMail/1.9.5 X-Face: g:jG2\O{-yqD1x?DG2lU1)(v%xffR"p8Nz(w/*)YEUO\Hn%mGi&-!+rq$&r64,=?utf-8?q?fuP=7E=3Bbw=5C=0A=09=5EQdX?=@v~HEAi?NaE8SU]}.oeYSjN84Fe{M(ahZ.(i+lxyP; pr)2[%mGbkY'RmM>=?utf-8?q?+mg3Y=24ip=0A=091?=@Z>[EUaE7tjJ=1DRs~:!uSd""d~:/Er3rpQA%ze|bp>S MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart83669293.9cMsPpfJQT"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200702101354.44165.lofi@freebsd.org> X-Virus-Scanned: by amavisd-new Subject: Crypto performance with focus on GELI-based disk encryption 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: Sat, 10 Feb 2007 15:29:50 -0000 --nextPart83669293.9cMsPpfJQT Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Does anyone have data on that subject? I'm planning to use GELI encryption = and=20 was wondering what options I might have for crypto acceleration hardware an= d=20 what performance gains (if any) I could expect from it. Cheers, =2D-=20 ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org --nextPart83669293.9cMsPpfJQT Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFzcCUXhc68WspdLARAlaHAJ9dD+xE6Ops7tpImgL5KIat/V/w/ACgjRv6 4/h50yBhFpQM0KB3IcZhQEg= =3cUu -----END PGP SIGNATURE----- --nextPart83669293.9cMsPpfJQT--