From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [Bugme-new] [Bug 9031] New: TPC window is to cautious on send Date: Sun, 16 Sep 2007 23:43:40 -0700 Message-ID: <20070916234340.dfe2e94e.akpm@linux-foundation.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: bugme-daemon@bugzilla.kernel.org, a@oo.ms To: netdev@vger.kernel.org Return-path: Received: from smtp2.linux-foundation.org ([207.189.120.14]:55796 "EHLO smtp2.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751854AbXIQGoa (ORCPT ); Mon, 17 Sep 2007 02:44:30 -0400 In-Reply-To: Sender: netdev-owner@vger.kernel.org List-Id: netdev.vger.kernel.org On Sun, 16 Sep 2007 17:02:46 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9031 > > Summary: TPC window is to cautious on send > Product: Networking > Version: 2.5 > KernelVersion: Any > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: IPV4 > AssignedTo: shemminger@osdl.org > ReportedBy: a@oo.ms > > > This has been a longstanding "bug" of sorts when talking to a system that has > extremely small windows (under 1.5k). > > The only way to give the stack on the other side a nudge is to ACK twice. > > Here is a sample transcript, with a max window size of 1025 bytes. > > 18:25:43.968358 IP dr.ea.ms.http > 192.168.80.2.40246: . 37377:37633(256) ack > 120 win 5840 > 18:25:43.992402 IP 192.168.80.2.40246 > dr.ea.ms.http: . ack 37121 win 769 256> > 18:25:44.390305 IP 192.168.80.2.40246 > dr.ea.ms.http: . ack 37121 win 1025 > > 18:25:44.823084 IP dr.ea.ms.http > 192.168.80.2.40246: . 37633:37889(256) ack > 120 win 5840 > > If I take the "nudge" code out of my IP stack, it sits for an aweful long time, > waiting on the next packet, when there clearly is room for a few more. > > Should I: > 1: Have my IP stack lie about the window till it is important? > 2: Something else? > > I can't see any good reason for the large delay, since it is on a serial link, > via SLIP. > > I can point you to source code that will allow you to verify the problem for > yourself, if you would like. >