From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Hemminger Subject: Re: 2.6.19-rc1: Volanomark slowdown Date: Wed, 8 Nov 2006 14:58:15 -0800 Message-ID: <20061108145815.25bb4c19@freekitty> References: <1162924354.10806.172.camel@localhost.localdomain> <1163001318.3138.346.camel@laptopd505.fenrus.org> <20061108162955.GA4364@suse.de> <1163011132.10806.189.camel@localhost.localdomain> <20061108221028.GA16889@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Tim Chen , Arjan van de Ven , linux-kernel@vger.kernel.org, davem@sunset.davemloft.net, kuznet@ms2.inr.ac.ru, netdev@vger.kernel.org Return-path: Received: from smtp.osdl.org ([65.172.181.4]:19374 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S1423863AbWKHW72 (ORCPT ); Wed, 8 Nov 2006 17:59:28 -0500 To: Olaf Kirch In-Reply-To: <20061108221028.GA16889@suse.de> Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Wed, 8 Nov 2006 23:10:28 +0100 Olaf Kirch 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 patch is applied. > > 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 Intel box for instance and it didn't > come close to saturating a Gigabit pipe before it maxed out on CPU load. > > > The total number of messages being exchanged around the chatrooms in > > Volanomark remain unchanged. But ACKS increase by 3.5 times and > > segments received increase by 38% from netstat. > > > So I think it is reasonable to conclude that the increase in TCP traffic > > reduce the bandwidth and throughput in Volanomark. > > You could count the number of outbound packets dropped on the server. > > Olaf Also under benchmark stress, the load can get so high that timers go off that normally don't. For example, I have seen delayed ack timer cause extra ack's when at lower loads the response happened quick enough that the ACK was piggybacked. -- Stephen Hemminger