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
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
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 orig
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
>
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 thou
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 4
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 is
> However, Volanomark is just a benchmark to alert us to changes.
> If in real applications with small segment, this patch is
> needed to fix congestion window adjustment as Dave pointed
> out, and impact on bandwidth not as important, so be it.
>
> Tim
if we can get the best of both worlds
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 e
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
I
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 Vo
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 v
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
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:
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 doing
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 e
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.o
17 matches
Mail list logo
