Re: Doubts about listen backlog and tcp_max_syn_backlog

On 01/25/2013 02:05 AM, Leandro Lucarella wrote: > On Thu, Jan 24, 2013 at 10:12:46PM -0800, Nivedita SInghvi wrote: >>>>> I was just kind of quoting the name given by netstat: "SYNs to LISTEN >>>>> sockets dropped" (for kernel 3.0, I noticed newer

Re: Doubts about listen backlog and tcp_max_syn_backlog

On 01/25/2013 02:05 AM, Leandro Lucarella wrote: > On Thu, Jan 24, 2013 at 10:12:46PM -0800, Nivedita SInghvi wrote: >>>>> I was just kind of quoting the name given by netstat: "SYNs to LISTEN >>>>> sockets dropped" (for kernel 3.0, I noticed newer

Re: Doubts about listen backlog and tcp_max_syn_backlog

On 01/25/2013 02:05 AM, Leandro Lucarella wrote: On Thu, Jan 24, 2013 at 10:12:46PM -0800, Nivedita SInghvi wrote: I was just kind of quoting the name given by netstat: SYNs to LISTEN sockets dropped (for kernel 3.0, I noticed newer kernels don't have this stat anymore, or the name was changed

Re: Doubts about listen backlog and tcp_max_syn_backlog

On 01/25/2013 02:05 AM, Leandro Lucarella wrote: On Thu, Jan 24, 2013 at 10:12:46PM -0800, Nivedita SInghvi wrote: I was just kind of quoting the name given by netstat: SYNs to LISTEN sockets dropped (for kernel 3.0, I noticed newer kernels don't have this stat anymore, or the name was changed

Re: Doubts about listen backlog and tcp_max_syn_backlog

On 01/24/2013 11:21 AM, Leandro Lucarella wrote: > On Thu, Jan 24, 2013 at 10:44:32AM -0800, Rick Jones wrote: >> On 01/24/2013 04:22 AM, Leandro Lucarella wrote: >>> On Wed, Jan 23, 2013 at 11:28:08AM -0800, Rick Jones wrote: > Then if syncookies are enabled, the time spent in connect()

Re: Doubts about listen backlog and tcp_max_syn_backlog

On 01/24/2013 11:21 AM, Leandro Lucarella wrote: On Thu, Jan 24, 2013 at 10:44:32AM -0800, Rick Jones wrote: On 01/24/2013 04:22 AM, Leandro Lucarella wrote: On Wed, Jan 23, 2013 at 11:28:08AM -0800, Rick Jones wrote: Then if syncookies are enabled, the time spent in connect() shouldn't be

[PATCH] MAINTAINERS: Update John Stultz email

John's email switched from IBM to Linaro. One less place for him to update now... Signed-off-by: Nivedita Singhvi --- MAINTAINERS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4e734ed..59e68d8 100644 --- a/MAINTAINERS +++ b

[PATCH] MAINTAINERS: Update John Stultz email

John's email switched from IBM to Linaro. One less place for him to update now... Signed-off-by: Nivedita Singhvi n...@us.ibm.com --- MAINTAINERS |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 4e734ed..59e68d8 100644 --- a/MAINTAINERS

Re: Poor UDP performance using 2.6.21-rc5-rt5

Dave Sperry wrote: Hi (adding netdev to cc list) I have a dual core Opteron machine that exhibits poor UDP performance (RT consumes more than 2X cpu) with the 2.6.21-rc5-rt5 as compared to 2.6.21-rc5. Top shows the IRQ handler consuming a lot of CPU. Dave, any chance you've got oprofile

Re: Poor UDP performance using 2.6.21-rc5-rt5

Dave Sperry wrote: Hi (adding netdev to cc list) I have a dual core Opteron machine that exhibits poor UDP performance (RT consumes more than 2X cpu) with the 2.6.21-rc5-rt5 as compared to 2.6.21-rc5. Top shows the IRQ handler consuming a lot of CPU. Dave, any chance you've got oprofile

Re: Client receives TCP packets but does not ACK

> The bad network behavior was due to shared irqs somehow screwing > things up. This explained most but not all of the problems. ah, that's why your test pgm succeeded on my systems.. > When I last posted I had a reproducible test case which spewed a bunch > of packets from a server to a

Re: Client receives TCP packets but does not ACK

The bad network behavior was due to shared irqs somehow screwing things up. This explained most but not all of the problems. ah, that's why your test pgm succeeded on my systems.. When I last posted I had a reproducible test case which spewed a bunch of packets from a server to a

Re: Abysmal RECV network performance

rone compared to tx), but that should affect all the kernel versions you ran on that host.. Am pretty clueless about media level issues, but it would help to identify whats causing the framing errors. Not much help, I know.. thanks, Nivedita --- Nivedita Singhvi

Re: Abysmal RECV network performance

level issues, but it would help to identify whats causing the framing errors. Not much help, I know.. thanks, Nivedita --- Nivedita Singhvi(503) 578-4580 Linux Technology Center [EMAIL PROTECTED] IBM Beaverton, OR [EMAIL PROTECTED

Re: Abysmal RECV network performance

are doing (tcp, mostly fast path) will not buy you any real performance gain, the checksum is actually consumed by the user-kernel copy routine. You can also run the tests on a profiling kernel and compare results... Nivedita --- Nivedita Singhvi(503) 578-4580 Linux Technol

Re: Abysmal RECV network performance

any real performance gain, the checksum is actually consumed by the user-kernel copy routine. You can also run the tests on a profiling kernel and compare results... Nivedita --- Nivedita Singhvi(503) 578-4580 Linux Technology Center [EMAIL PROTECTED] IBM

netperf stream scaling; patches that help?

on this list on 4/12, are there any others? I know Jonathan Morton posted some OOM patches, are those included in 2.4.4? thanks, Nivedita --- Nivedita Singhvi(503) 578-4580 Linux Technology Center [EMAIL PROTECTED] IBM Beaverton, OR [EMAIL

netperf stream scaling; patches that help?

on this list on 4/12, are there any others? I know Jonathan Morton posted some OOM patches, are those included in 2.4.4? thanks, Nivedita --- Nivedita Singhvi(503) 578-4580 Linux Technology Center [EMAIL PROTECTED] IBM Beaverton, OR [EMAIL