From owner-freebsd-stable@FreeBSD.ORG Tue Jun 24 08:19:36 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B53B3106564A; Tue, 24 Jun 2008 08:19:36 +0000 (UTC) (envelope-from quakenet1@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 33F798FC19; Tue, 24 Jun 2008 08:19:35 +0000 (UTC) (envelope-from quakenet1@optusnet.com.au) Received: from [10.0.2.3] (c122-106-190-227.belrs3.nsw.optusnet.com.au [122.106.190.227]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m5O8JSWQ008928; Tue, 24 Jun 2008 18:19:29 +1000 Message-Id: <25CC6491-DB3F-4B06-A17F-E6C93A3CAD5D@optusnet.com.au> From: Jerahmy Pocott To: freebsd-stable@freebsd.org In-Reply-To: <200806231642.m5NGggV8089156@apollo.backplane.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Tue, 24 Jun 2008 18:19:26 +1000 References: <0222EAC1-A278-41D2-9566-C9CF19811068@optusnet.com.au> <200806230827.m5N8RBlW085475@apollo.backplane.com> <485F7576.5070104@freebsd.org> <200806231642.m5NGggV8089156@apollo.backplane.com> X-Mailer: Apple Mail (2.924) Cc: Subject: Re: Sysctl knob(s) to set TCP 'nagle' time-out? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2008 08:19:36 -0000 On 24/06/2008, at 2:42 AM, Matthew Dillon wrote: > It should be noted that Nagle can cause high latencies even when > delayed acks are turned off. Nagle's delay is not timed... in its > simplest description it prevents packets from being transmitted > for new data coming from userland if the data already in the > sockbuf (and presumably already transmitted) has not yet been > acknowledged. Assuming that a full data packet can't be constructed in the time it takes for the acknowledgement. If you CAN construct a whole packet in that time then Nagle is either doing a good job or you're sending large amounts of data.. Perhaps nagle a) needs a time out, though I don't really think that would help, or b) uses a dynamic 'in-flight' count where it tries to maintain x packets in-flight and only holds packets up when that value is reached.. The idea being that you get the ack on your first packet at the same time as the host should be getting your second packet.. That way you still get to concatenate lots of small packets being generated in a short space of time, but don't hold up sending data because of the ack latency. It should also be possible to detect if the remote host is using delayed acks and compensate for that? Though I'v not considered it in much detail..