From owner-freebsd-stable Fri Nov 9 13:47:23 2001 Delivered-To: freebsd-stable@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.123.66]) by hub.freebsd.org (Postfix) with ESMTP id 3875737B417; Fri, 9 Nov 2001 13:47:19 -0800 (PST) Received: from caddis.yogotech.com (caddis.yogotech.com [206.127.123.130]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id OAA24169; Fri, 9 Nov 2001 14:47:17 -0700 (MST) (envelope-from nate@yogotech.com) Received: (from nate@localhost) by caddis.yogotech.com (8.11.6/8.11.6) id fA9LlCb49215; Fri, 9 Nov 2001 14:47:12 -0700 (MST) (envelope-from nate) From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15340.20191.441648.662113@caddis.yogotech.com> Date: Fri, 9 Nov 2001 14:47:11 -0700 To: stable@FreeBSD.org Cc: jayanth@FreeBSD.org Subject: TCP NewReno causing wild performance fluctuations X-Mailer: VM 6.96 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG We've been using FreeBSD boxes as our reference ftp servers at work, and because of the recent security issues, I've went through and updated a number of our public boxes from 3.x -> 4.4. However, we're seeing significant variations in ftp throughput from boxes that are directly connected on the lan segment. If I disable the New Reno code, things go back to normal (ie; no fluctuations). I went through the logfiles, and it turns out there has been one fix to the code that hasn't been merged into stable. Rev1.139 in tcp_input.c has not (yet) been merged into -stable. revision 1.139 date: 2001/08/29 23:54:13; author: jayanth; state: Exp; lines: +3 -1 when newreno is turned on, if dupacks = 1 or dupacks = 2 and new data is acknowledged, reset the dupacks to 0. The problem was spotted when a connection had its send buffer full because the congestion window was only 1 MSS and was not being incremented because dupacks was not reset to 0. Obtained from: Yahoo! I hand-merged this change back onto my box, installed a new kernel, and now in my *very* minor testing things appear to be more normal. My question is should this fix be merged into stable, and would the lack of this bugfix explain my performance results? Unfortunately, I don't haven't gotten any tcpdump outputs to analyze what was going on, but I didn't want this bugfix to slip through the cracks. Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message