kernel: sonewconn: pcb 0xfe0047db3930: Listen queue overflow: 193 already in
queue awaiting acceptance
last message repeated 113 times
last message repeated 518 times
last message repeated 2413 times
last message repeated 2041 times
last message repeated 1741 times
last message repeated 1543 ti
On 11.07.2013 09:05, Andriy Gapon wrote:
kernel: sonewconn: pcb 0xfe0047db3930: Listen queue overflow: 193 already in
queue awaiting acceptance
last message repeated 113 times
last message repeated 518 times
last message repeated 2413 times
last message repeated 2041 times
last message repeat
On 10.07.2013 15:18, Fabian Keil wrote:
Andre Oppermann wrote:
We have a SYN cookie implementation for quite some time now but it
has some limitations with current realities for window scaling and
SACK encoding the in the few available bits.
This patch updates and improves SYN cookies mainly
On Thu, Jul 11, 2013 at 09:19:40AM +0200, Andre Oppermann wrote:
A> On 11.07.2013 09:05, Andriy Gapon wrote:
A> > kernel: sonewconn: pcb 0xfe0047db3930: Listen queue overflow: 193
already in
A> > queue awaiting acceptance
A> > last message repeated 113 times
A> > last message repeated 518 time
On 11.07.2013 15:35, Gleb Smirnoff wrote:
On Thu, Jul 11, 2013 at 09:19:40AM +0200, Andre Oppermann wrote:
A> On 11.07.2013 09:05, Andriy Gapon wrote:
A> > kernel: sonewconn: pcb 0xfe0047db3930: Listen queue overflow: 193
already in
A> > queue awaiting acceptance
A> > last message repeated 1
On Thu, Jul 11, 2013 at 4:28 PM, Andre Oppermann wrote:
> On 11.07.2013 15:35, Gleb Smirnoff wrote:
>>
>> On Thu, Jul 11, 2013 at 09:19:40AM +0200, Andre Oppermann wrote:
>> A> On 11.07.2013 09:05, Andriy Gapon wrote:
>> A> > kernel: sonewconn: pcb 0xfe0047db3930: Listen queue overflow: 193
>>
On Thu, Jul 11, 2013 at 04:49:25PM +0200, Luigi Rizzo wrote:
L> >> IMO, this should be a single counter accessible via sysctl, with no
L> >> printf(). Those, who need details on whether this is micro-burst or
L> >> persistent condition, can run monitoring software that draws plots.
L> >
L> >
L> > T
on 11/07/2013 17:28 Andre Oppermann said the following:
> Andriy for example would never have found out about this problem other
> than receiving vague user complaints about aborted connection attempts.
> Maybe after spending many hours searching for the cause he may have
> interfered from endless
On Thu, Jul 11, 2013 at 4:52 PM, Gleb Smirnoff wrote:
> On Thu, Jul 11, 2013 at 04:49:25PM +0200, Luigi Rizzo wrote:
> L> >> IMO, this should be a single counter accessible via sysctl, with no
> L> >> printf(). Those, who need details on whether this is micro-burst or
> L> >> persistent condition,
On 11.07.2013 17:04, Andriy Gapon wrote:
on 11/07/2013 17:28 Andre Oppermann said the following:
Andriy for example would never have found out about this problem other
than receiving vague user complaints about aborted connection attempts.
Maybe after spending many hours searching for the cause
Old Synopsis: LOCAL_PEERCRED support for PF_INET
New Synopsis: [request] LOCAL_PEERCRED support for PF_INET
State-Changed-From-To: open->suspended
State-Changed-By: linimon
State-Changed-When: Thu Jul 11 15:47:12 UTC 2013
State-Changed-Why:
Feature request. Mark as suspended awaiting someone to
on 11/07/2013 18:43 Andre Oppermann said the following:
> I'm currently looking into a) applying a rate limiter to the message (as
> suggested
> by Luigi); and b) add a per-socket accept queue overflow statistic that is
> visible
> via netstat. I'll post patches for testing when done.
Thank you
On Wednesday, July 10, 2013 6:59:42 am lini...@freebsd.org wrote:
> Old Synopsis: Bad UDP checksum calc for fragmented packets
> New Synopsis: [ofed] [patch] Bad UDP checksum calc for fragmented packets
>
> Responsible-Changed-From-To: freebsd-bugs->freebsd-net
> Responsible-Changed-By: linimon
>
Hi! I have a problem with my FreeBSD router, I can't get more than 1 Gbps
throught it, but I have 2 Gbps LAGG on it. There are only 27 IPFW rules
(NAT+Shaping). IPoE only.
lagg0 (VLAN's + shaping) - two 'igb' adapters
lagg1 (NAT, tso if off) - two 'em' adapters
I tried to switch off dummynet, b
How are you benchmarking it? Each TCP connection only uses one member
of a lagg port. So if you want to see > 1 Gbps, you'll need to
benchmark with multiple TCP connections. You may also need multiple
systems; I don't know the full details of LACP.
On Thu, Jul 11, 2013 at 11:32 AM, isp wrote:
I have a real network with more than 4 000 users. In normal case, when I
have two 1Gbps routers, and I split VLAN's between them total bandwidth
if growing up to 1.7 Gbps.
--- Incoming mail ---
From: "Alan Somers"
Date: 11 July 2013, 21:00:41
How are you benchmarking it? Each TCP connection
16 matches
Mail list logo