From owner-freebsd-bugs@FreeBSD.ORG Thu Apr 13 20:34:48 2006 Return-Path: X-Original-To: freebsd-bugs@FreeBSD.org Delivered-To: freebsd-bugs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EFC616A400 for ; Thu, 13 Apr 2006 20:34:48 +0000 (UTC) (envelope-from dwmalone@maths.tcd.ie) Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by mx1.FreeBSD.org (Postfix) with SMTP id D899C43D46 for ; Thu, 13 Apr 2006 20:34:47 +0000 (GMT) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie ([134.226.81.10] helo=walton.maths.tcd.ie) by salmon.maths.tcd.ie with SMTP id ; 13 Apr 2006 21:34:46 +0100 (BST) Date: Thu, 13 Apr 2006 21:34:46 +0100 From: David Malone To: Dan Nelson Message-ID: <20060413203446.GA21222@walton.maths.tcd.ie> References: <200502080720.j187KGr5038302@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200502080720.j187KGr5038302@freefall.freebsd.org> User-Agent: Mutt/1.5.6i Sender: dwmalone@maths.tcd.ie Cc: freebsd-bugs@FreeBSD.org Subject: Re: kern/75122: [PATCH] Incorrect inflight bandwidth calculation on first packet X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2006 20:34:48 -0000 Hi Dan, A couple of questions on the patch: > Index: tcp_hostcache.c I guess the hostcache stuff isn't actually part of the inflight limiting changes? > + if (tp->snd_bandwidth == 0) > + tp->snd_bandwidth = tcp_inflight_min; Unless I'm wrong, this code doesn't make a lot of sense. It is trying to stop the bandwidth estimate being too small after startup/idle. However, snd_bandwidth is in units of bandwidth, but tcp_inflight_min is a window size in bytes. Do you know if this is being triggered much? I'm not sure this if statement will actually help inflight limiting deal with corner cases like this anyway - the tcp_inflight_min already stops it doing too much damage in situations where TCP has been transmitting a low (or zero) rate stream and suddenly wants to start sending more. (Since inflight limiting uses an rttbest including the varience and then averages that with the current rtt estimate, it should not be that close to the edge?) David.