Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759551Ab0GQAgt (ORCPT ); Fri, 16 Jul 2010 20:36:49 -0400 Received: from mail-qw0-f46.google.com ([209.85.216.46]:50640 "EHLO mail-qw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755314Ab0GQAgr convert rfc822-to-8bit (ORCPT ); Fri, 16 Jul 2010 20:36:47 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=AWOexyvXDp4rQvRS6j806mJCU2A1dHdj1s2rdd1HMrBa5nvnTFYpffUhk2ZmAjCYYP lK0OB1JulhmU01yqpLNOun79ULnhRugWLx3CvXIwT/D20G1jSBv3GhW21Cl+sY5Azrj/ v3wl9BQdv8rbiEuisnjob6INs+0r3n4YQ8ThA= MIME-Version: 1.0 In-Reply-To: <1279299709.2156.5814.camel@tng> References: <4C3D94E3.9080103@wildgooses.com> <4C3DD5EB.9070908@tmr.com> <20100714.111553.104052157.davem@davemloft.net> <1279299709.2156.5814.camel@tng> Date: Fri, 16 Jul 2010 17:36:46 -0700 Message-ID: Subject: Re: Raise initial congestion window size / speedup slow start? From: "H.K. Jerry Chu" To: Patrick McManus Cc: David Miller , davidsen@tmr.com, lists@wildgooses.com, linux-kernel@vger.kernel.org, netdev@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2129 Lines: 54 On Fri, Jul 16, 2010 at 10:01 AM, Patrick McManus wrote: > On Wed, 2010-07-14 at 21:51 -0700, H.K. Jerry Chu wrote: >> ?except there are indeed bugs in the code today in that the >> code in various places assumes initcwnd as per RFC3390. So when >> initcwnd is raised, that actual value may be limited unnecessarily by >> the initial wmem/sk_sndbuf. > > Thanks for the discussion! > > can you tell us more about the impl concerns of initcwnd stored on the > route? We have found two issues when altering initcwnd through the ip route cmd: 1. initcwnd is actually capped by sndbuf (i.e., tcp_wmem[1], which is defaulted to a small value of 16KB). This problem has been made obscured by the TSO code, which fudges the flow control limit (and could be a bug by itself). 2. the congestion backoff code is supposed to take inflight, rather than cwnd, but initcwnd presents a special case. I don't fully understand the code yet to propose a fix. > > and while I'm asking for info, can you expand on the conclusion > regarding poor cache hit rates for reusing learned cwnds? (ok, I admit I > only read the slides.. maybe the paper has more info?) This is partly due to our load balancer policy resulting in poor cache hit, partly due to the sheer volumes of remote clients. Some of colleagues tried to change the host cache to a /24 subnet cache but the result wasn't that good either (sorry I don't remember all the details.) > > article and slides much appreciated and very interetsing. I've long been > of the opinion that the downsides of being too aggressive once in a > while aren't all that serious anymore.. as someone else said in a > non-reservation world you are always trying to predict the future anyhow > and therefore overflowing a queue is always possible no matter how > conservative. Please voice your support to TCPM then :) Jerry > > > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/