From owner-freebsd-net Wed Apr 21 22:27:40 1999 Delivered-To: freebsd-net@freebsd.org Received: from implode.root.com (root.com [209.102.106.178]) by hub.freebsd.org (Postfix) with ESMTP id B32D214F65 for ; Wed, 21 Apr 1999 22:27:38 -0700 (PDT) (envelope-from root@implode.root.com) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.8/8.8.5) with ESMTP id WAA16883; Wed, 21 Apr 1999 22:24:00 -0700 (PDT) Message-Id: <199904220524.WAA16883@implode.root.com> To: Alex Rousskov Cc: freebsd-net@FreeBSD.ORG Subject: Re: _Some_ acks delayed for 200 msec? In-reply-to: Your message of "Wed, 21 Apr 1999 23:16:07 MDT." From: David Greenman Reply-To: dg@root.com Date: Wed, 21 Apr 1999 22:24:00 -0700 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >On Wed, 21 Apr 1999, David Greenman wrote: > >> >Now, if that is the infamous delayed ack problem, then >> > - why only *some* acks are delayed? >> >> Probably because of timing of the response packets. It's impossible to >> say with your limited, one-sided tcpdump. > >Response packets are coming as soon as an ack is sent or prior to that, as >far as I can tell. There was a small bi-directional tcpdump in the original >post. By "one-sided", do you mean a dump collected on a single [client] >host, or that server responses were filtered out in the long dump that I >sent? I can certainly provide more info. Just tell me what would be useful. >I was afraid of posting long tcpdumps... I mean both. >> The Nagle algorithm doesn't know or care about "local" networks. > >Right. I confused Nagle with TCP_ACK_HACK (which is sort of a Nagle-like >algorithm). TCP_ACK_HACK (a sysctl option in 3.1) does depend on network >"locality" from our experience. > >> > - why disabling Nagle (TCP_NODELAY) does not help? >> >> It will likely have to be disabled on both sides for your application since >> there appears to be a syncronous request/response involved. > >It was disabled on both sides. I'm not familiar with what your application is doing over the wire, so I can only speculate. It sounds to me as though TCP_NODELAY wasn't actually set properly on the socket. Keep in mind that this option is not inherited in the accept()'ed file descriptor and thus the option must be set on that descriptor and not on the listen() socket. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message