On Fri, Oct 9, 2009 at 1:45 AM, Pyun YongHyeon wrote:
> On Thu, Oct 08, 2009 at 01:24:20PM +0800, Siquijor Philips wrote:
>> Hi,
>>
>> I got a dual-port Intel Gigabit NIC with 82576 (ET) chipset
>> http://www.intel.com/Assets/PDF/prodbrief/320116.pdf. It has a feature
>> on IPsec offloading but it
I've been running the attached patch for a month on routers in production.
To summarize:
* Routing daemons listen to routing messages.
* Without the patch routing messages all FIBs are sent to
all listeners.
* Routing daemons get confused.
This patch makes routing daemons listening to routi
On Thu, Oct 08, 2009 at 01:24:20PM +0800, Siquijor Philips wrote:
> Hi,
>
> I got a dual-port Intel Gigabit NIC with 82576 (ET) chipset
> http://www.intel.com/Assets/PDF/prodbrief/320116.pdf. It has a feature
> on IPsec offloading but it only mentioned Microsoft Windows 2008 and
> Vista servers. I
Julian Elischer wrote:
you can not do anything about it if one of the custommers sends a burst
of 3000 udp packets at their maximum speed(or maybe some combination of
custommers to something which results in an aggreagate burst rate like
that.
In other words you may always continue to get mome
Julian Elischer wrote:
tee & ngtee are similar with one_pass=0 and different with one_pass=1
that seems like a bug to me..
neither tee should ever terminate a search.
if you want to terminate it, add a specific rule to do so.
Unfortunately I wasn't involved in writing it.
+1
ngtee shouldn'
rihad wrote:
Robert Watson wrote:
I would suggest making just the HZ -> 4000 change for now and see how
it goes.
2018 users online, 73 drops have just occurred.
p.s.: already 123 drops.
It will only get worse after some time.
Traffic load: 440-450 mbps.
top -HS:
last pid: 68314; load averag
Oleg Bulyzhin wrote:
On Wed, Oct 07, 2009 at 09:42:27PM +0500, rihad wrote:
Julian Elischer wrote:
rihad wrote:
Oleg Bulyzhin wrote:
You probably have some special sources of documentation ;-) According
to man ipfw, both "netgraph/ngtee" and "pipe" decide the fate of the
packet unless one_pa
Ian Smith wrote:
On Wed, 7 Oct 2009, rihad wrote:
> Robert Watson wrote:
>
> > I would suggest making just the HZ -> 4000 change for now and see how it
> > goes.
> >
> OK, I will try testing HZ=4000 tomorrow morning, although I'm pretty sure
> there still will be some drops.
Even if
Robert Watson wrote:
I would suggest making just the HZ -> 4000 change for now and see how
it goes.
~4000 online users, ~450-470 mbps traffic, 300-600 global drops per
second. Same ole. Not funny at all.
net.inet.ip.dummynet.io_pkt_drop: 0
net.inet.ip.intr_queue_drops: 0
net.inet.ip.fastforwa
Robert Watson wrote:
I would suggest making just the HZ -> 4000 change for now and see how
it goes.
2018 users online, 73 drops have just occurred.
p.s.: already 123 drops.
It will only get worse after some time.
Traffic load: 440-450 mbps.
top -HS:
last pid: 68314; load averages: 1.35, 1.
Robert Watson wrote:
I would suggest making just the HZ -> 4000 change for now and see how it
goes.
Been running for a few hours under these changed sysctls:
kern.clockrate: { hz = 4000, tick = 250, profhz = 4000, stathz = 129 }
net.inet.ip.dummynet.io_fast: 1
net.inet.ip.dummynet.hash_size: 5
On Wed, 7 Oct 2009, rihad wrote:
> Robert Watson wrote:
>
> > I would suggest making just the HZ -> 4000 change for now and see how it
> > goes.
> >
> OK, I will try testing HZ=4000 tomorrow morning, although I'm pretty sure
> there still will be some drops.
Even if there are, I'd like t
If you really want to make the switch to 10G I would also seriously consider
moving to
FreeBSD 8, the changes that have been made in the stack will help you get
the most
out of the hardware.
When it comes to Intel hardware the model Andrew cites is the CX4 version of
the 82598, you
can also get
13 matches
Mail list logo
