On Wed, Nov 08, 2006 at 02:07:32PM -0800, Tim Chen wrote:
In my testing, the CPU utilization is at 100%. So
increase in ACKs will cost CPU to devote more
time to process those ACKs and reduce throughput.
Oh, I see. I would test on a real network with real clients. I doubt
you would observe a
Hell]!
reduced Volanomark benchmark throughput by 10%.
The irony of it is that java vm used to be one of victims
of over-delayed acks.
I will look, there is a little chance that it is possible
to detect the situation and to stretch ACKs.
There is one little question though. If you see a
On Tue, 2006-11-07 at 10:32 -0800, Tim Chen wrote:
The patch
[TCP]: Send ACKs each 2nd received segment
commit: 1ef9696c909060ccdae3ade245ca88692b49285b
http://kernel.org/git/?
p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=1ef9696c909060ccdae3ade245ca88692b49285b
reduced
On Wed, Nov 08, 2006 at 04:55:18PM +0100, Arjan van de Ven wrote:
I wonder if it's an option to use low priority QoS fields for these acks
(heck I don't even know if ACKs have such fields in their packet) so
that they can get dropped if there are more packets then there is
bandwidth
Is
On Wed, 2006-11-08 at 17:29 +0100, Olaf Kirch wrote:
Is it proven that the number of ACKs actually cause bandwidth problems?
I found Volanomark to exercise the scheduler more than anything else,
so maybe the slowdown, while triggered by an increased number of ACKs,
is caused by something else
On Wed, Nov 08, 2006 at 10:38:52AM -0800, Tim Chen wrote:
The patch in question affects purely TCP and not the scheduler. I don't
I know.
think the scheduler has anything to do with the slowdown seen after
the patch is applied.
In fixing performance issues, the most obvious explanation
On Wed, 2006-11-08 at 23:10 +0100, Olaf Kirch wrote:
In fixing performance issues, the most obvious explanation isn't always
the right one. It's quite possible you're right, sure.
What I'm saying though is that it doesn't rhyme with what I've seen of
Volanomark - we ran 2.6.16 on a 4p
On Wed, 08 Nov 2006 14:07:32 -0800
Tim Chen [EMAIL PROTECTED] wrote:
On Wed, 2006-11-08 at 23:10 +0100, Olaf Kirch wrote:
In fixing performance issues, the most obvious explanation isn't always
the right one. It's quite possible you're right, sure.
What I'm saying though is that it
On Wed, 8 Nov 2006 23:10:28 +0100
Olaf Kirch [EMAIL PROTECTED] wrote:
On Wed, Nov 08, 2006 at 10:38:52AM -0800, Tim Chen wrote:
The patch in question affects purely TCP and not the scheduler. I don't
I know.
think the scheduler has anything to do with the slowdown seen after
the
On Wed, 2006-11-08 at 15:00 -0800, Stephen Hemminger wrote:
Optimizing for loopback is perversion; perversion can be fun but it gets
to be a obsession then it's sick.
It is not my intention to optimize for this case, but rather to
detect change in kernel behavior.
That's why in my
On Wed, 2006-11-08 at 23:10 +0100, Olaf Kirch wrote:
What I'm saying though is that it doesn't rhyme with what I've seen of
Volanomark - we ran 2.6.16 on a 4p Intel box for instance and it didn't
come close to saturating a Gigabit pipe before it maxed out on CPU load.
That actually supports
Begin forwarded message:
Date: Tue, 07 Nov 2006 10:32:34 -0800
From: Tim Chen [EMAIL PROTECTED]
Newsgroups: linux.dev.kernel
Subject: 2.6.19-rc1: Volanomark slowdown
The patch
[TCP]: Send ACKs each 2nd received segment
commit: 1ef9696c909060ccdae3ade245ca88692b49285b
http://kernel.org/git
From: Tim Chen [EMAIL PROTECTED]
Date: Tue, 07 Nov 2006 10:32:34 -0800
[ Please bring up networking questions on netdev@vger.kernel.org
as that is the place where networking developers read bug reports
and questions, they by-in-large do not read linux-kernel at all. ]
[TCP]: Send ACKs each
David Miller wrote:
If we don't ACK every two segments, stacks which grow the congestion
window based upon packet counting will not grow the congestion window
properly when they are sending smaller than MSS sized segments.
The only stack I know of that does this currently is linux, and in
From: John Heffner [EMAIL PROTECTED]
Date: Tue, 07 Nov 2006 16:50:33 -0500
The only stack I know of that does this currently is linux, and in doing
so does not conform to the spec. ;) Sending to a BSD receiver will
result in the same behavior, so the right place to fix this is on the
David Miller wrote:
From: John Heffner [EMAIL PROTECTED]
Date: Tue, 07 Nov 2006 16:50:33 -0500
The only stack I know of that does this currently is linux, and in doing
so does not conform to the spec. ;) Sending to a BSD receiver will
result in the same behavior, so the right place to fix
16 matches
Mail list logo
