Re: Performance degradation after upgrade

2011-04-06 Thread Peter Hallin
On 2011-04-05 14:35, Claudio Jeker wrote: Can you give the following diff a spin and see if that makes the card act faster. This disables the ppb hotplug interrupt which is shared with the em2 and em3 interrupts. -- :wq Claudio Ok, that did the trick. I made the changes to the 4.8 source

Re: Performance degradation after upgrade

2011-04-06 Thread Claudio Jeker
On Wed, Apr 06, 2011 at 01:22:41PM +0200, Peter Hallin wrote: On 2011-04-05 14:35, Claudio Jeker wrote: Can you give the following diff a spin and see if that makes the card act faster. This disables the ppb hotplug interrupt which is shared with the em2 and em3 interrupts. -- :wq

Re: Performance degradation after upgrade

2011-04-06 Thread Claudio Jeker
On Wed, Apr 06, 2011 at 03:55:03PM +0200, Claudio Jeker wrote: On Wed, Apr 06, 2011 at 01:22:41PM +0200, Peter Hallin wrote: On 2011-04-05 14:35, Claudio Jeker wrote: Can you give the following diff a spin and see if that makes the card act faster. This disables the ppb hotplug interrupt

Re: Performance degradation after upgrade

2011-04-06 Thread Ted Unangst
On Wed, Apr 6, 2011 at 9:55 AM, Claudio Jeker cje...@diehard.n-r-g.com wrote: Here is a better version that may get commited if it works for you. Currently only amd64 is fixed, we're looking into i386 to do the same dance with the interrupt return values. So the idea is to establish the

Re: Performance degradation after upgrade

2011-04-06 Thread Peter Hallin
On 2011-04-06 16:43, Claudio Jeker wrote: Wait. It seems more is needed. Will come back when we have a better solution. Alright. Your first quick fix is good enough for us, we don't use expresscards in our firewalls.. ;) I actually tested it on an older 4.4 fw that has been under heavy

Re: Performance degradation after upgrade

2011-04-05 Thread Peter Hallin
OK, here's a little update on this problem. As I told you earlier in the thread, we did some successful tests with the 4-port Intel 82576 card, HOWEVER we only tested two ports, em0 och em1. When the card later was put into the production machine we chose to use em0 as the unprocteded if and em2

Re: Performance degradation after upgrade

2011-04-05 Thread Claudio Jeker
On Tue, Apr 05, 2011 at 02:16:33PM +0200, Peter Hallin wrote: OK, here's a little update on this problem. As I told you earlier in the thread, we did some successful tests with the 4-port Intel 82576 card, HOWEVER we only tested two ports, em0 och em1. When the card later was put into the

Re: Performance degradation after upgrade

2011-03-31 Thread Peter Hallin
On 2011-03-30 21:18, Rodrigo Mosconi wrote: Just as curiosity: Did you used both ports from the Intel Pro/1000 PCIe (82576)? And if is used a single port PCI-Ex Intel Card? This is what we have tested today: 1. One dual port PCIe, with port 1 (em0) bridged with port 2 (em1), with bad

Re: Performance degradation after upgrade

2011-03-31 Thread Peter Hallin
On 2011-03-30 14:27, Claudio Jeker wrote: Could you donate a dual port card to the project if you replace them? I would like to figure out why some em(4) perform badly while the same chip on a different card seems to perform as expected. Can you provide the vmstat -zi output of the 4 port

Re: Performance degradation after upgrade

2011-03-30 Thread Peter Hallin
Ok, now we have been doing some testing and probably found the problem. All tests were done on the same machine with an Intel S5000VSA MB and a Xeon E5420 2,5 Ghz processor, running OpenBSD 4.8 amd64 GENERIC (SP kernel). We tested the performance with iperf, running two clients connected through

Re: Performance degradation after upgrade

2011-03-30 Thread Claudio Jeker
Could you donate a dual port card to the project if you replace them? I would like to figure out why some em(4) perform badly while the same chip on a different card seems to perform as expected. Can you provide the vmstat -zi output of the 4 port card? I wonder how the interrupts are shared on

Re: Performance degradation after upgrade

2011-03-30 Thread Rodrigo Mosconi
2011/3/30 Peter Hallin peter.hal...@ldc.lu.se Ok, now we have been doing some testing and probably found the problem. All tests were done on the same machine with an Intel S5000VSA MB and a Xeon E5420 2,5 Ghz processor, running OpenBSD 4.8 amd64 GENERIC (SP kernel). We tested the

Performance degradation after upgrade

2011-03-28 Thread Peter Hallin
Hello all, Last saturday during a service window, we installed a new firewall as a replacement to one of our oldest firewalls that had been running at a very high load for a long time. The old fw ran 3.9 (i386, SP) on a Pentium4 3.2Ghz and was able to forward data at about 300 Mbit/s at 100% CPu

Re: Performance degradation after upgrade

2011-03-28 Thread Tomas Bodzar
see archives on misc@ about month ago or so there was thread about something similar. New SMP HW with a lot of cores doesn't mean automatically better FW or speed. On Mon, Mar 28, 2011 at 11:27 AM, Peter Hallin peter.hal...@ldc.lu.se wrote: Hello all, Last saturday during a service window, we

Re: Performance degradation after upgrade

2011-03-28 Thread Tomas Bodzar
This one to be concrete http://marc.info/?l=openbsd-miscm=129839483317022w=2 On Mon, Mar 28, 2011 at 11:27 AM, Peter Hallin peter.hal...@ldc.lu.se wrote: Hello all, Last saturday during a service window, we installed a new firewall as a replacement to one of our oldest firewalls that had been

Re: Performance degradation after upgrade

2011-03-28 Thread Jonathan Gray
It sounds like you have an interrupt storm what does vmstat -iz show?

Re: Performance degradation after upgrade

2011-03-28 Thread Peter Hallin
This is the output when the machine is running at 80 Mbit/s and CPU usage is almost 100% interrupts: Please note that this is after we rebooted with the SP kernel, which didn't make any differences. systat ifs: IFACE STATE DESC IPKTS IBYTESIERRSOPKTS

Re: Performance degradation after upgrade

2011-03-28 Thread Peter Hallin
I realized now that this measurement is wrong. vmstat -iz seems to calculate the interrupt rate based a longer period, and this measurement was taken just after we started to push traffic through the machine again. The amount of interrupts per second when checking with systat (which seems to