From owner-freebsd-stable@FreeBSD.ORG Mon Jun 23 09:14:06 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 E701B1065673 for ; Mon, 23 Jun 2008 09:14:06 +0000 (UTC) (envelope-from quakenet1@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 86F838FC15 for ; Mon, 23 Jun 2008 09:14:06 +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 mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m5N9E06t008014; Mon, 23 Jun 2008 19:14:00 +1000 Message-Id: From: Jerahmy Pocott To: Matthew Dillon In-Reply-To: <200806230827.m5N8RBlW085475@apollo.backplane.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v924) Date: Mon, 23 Jun 2008 19:13:55 +1000 References: <0222EAC1-A278-41D2-9566-C9CF19811068@optusnet.com.au> <200806230827.m5N8RBlW085475@apollo.backplane.com> X-Mailer: Apple Mail (2.924) Cc: freebsd-stable@freebsd.org 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: Mon, 23 Jun 2008 09:14:07 -0000 On 23/06/2008, at 6:27 PM, Matthew Dillon wrote: > Can it break down and cause excessive lag? Yes, it can. > Interactive > games almost universally have to disable Nagle because the lag is > actually due to the data relay from client 1 -> server then > relaying > the interactive event to client 2. Without an immediate > interactive > response to client 1 the ack gets delayed and the next event from > client 1 hits Nagle and stops dead in the water until the first > event > reaches client 2 and client 2 reacts to it (then client 2 -> > server -> > (abort delayed ack and send) -> client 1 (client 1's nagle now > allows > the second event to be transmitted). That isn't a deadlock, just > really poor interactive performance in that particular situation. Yeah, that's what I'm talking about. True, it's not really a dead-lock, but it's terribly slow! The interaction can cause a 200ms delay on a LAN, as can be seen with samba if you disable tcp_nodelay.. > In anycase, the usual solution is to disable Nagle rather then mess > with delayed acks. What we need is a new Nagle that understands > the > new reality for interactive connections... something that doesn't > break > performance in the 'server in the middle' data relaying case. Exactly, there is nothing really wrong with delayed acks.. But with sysctl I CAN disable and mess with the delayed acks, but I can't seem to do anything to Nagle. That's why I was thinking if I could change the Nagle time-out to 0ms it would effectively disable it.. Cheers. J.