From owner-freebsd-net Sat Feb 24 12:28:49 2001 Delivered-To: freebsd-net@freebsd.org Received: from prism.flugsvamp.com (cb58709-a.mdsn1.wi.home.com [24.17.241.9]) by hub.freebsd.org (Postfix) with ESMTP id C7B7437B401 for ; Sat, 24 Feb 2001 12:28:46 -0800 (PST) (envelope-from jlemon@flugsvamp.com) Received: (from jlemon@localhost) by prism.flugsvamp.com (8.11.0/8.11.0) id f1OKRgP36070; Sat, 24 Feb 2001 14:27:42 -0600 (CST) (envelope-from jlemon) Date: Sat, 24 Feb 2001 14:27:42 -0600 From: Jonathan Lemon To: Mark Peek Cc: Paul Herman , Garrett Wollman , Jonathan Lemon , net@FreeBSD.ORG Subject: Re: I have delayed ACK problems Message-ID: <20010224142742.T5714@prism.flugsvamp.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Feb 24, 2001 at 11:19:02AM -0800, Mark Peek wrote: > At 11:19 PM +0100 1/25/01, Paul Herman wrote: > >On Thu, 25 Jan 2001, Garrett Wollman wrote: > > > >> < >> said: > >> > >> The important part was the > >> if (callout_pending(tp->tt_delack)) { > >> ... > >> tp->t_flags |= TF_ACKNOW; > >> } > >> > >> bit. This causes us to ack immediately where previously we would just > >> delay an already-schedule delayed ack. > > > >Yep, that does it. Simple. Elegant. I see now why my (bloated > >unintelligible) patch worked, it also didn't reset the timer when a > >delayed ack might have already been pending. > > > >OK, there are other parts of the code that do the same thing > >(TCP_REASS, SYN was ACKed, et. al.) but if no one objects, I'll > >send-pr the patch to be commited. > > Was there ever a final resolution to this problem? I checked CVS and > there didn't appear to be any code changes made as a result of this > discussion. If this was a real problem, I'm wondering whether it > should be checked into -current and considered for MFC into 4.3. The patches are still sitting in my tree, as I've been unable to come up with a test case that actually makes a difference. The "tar cf host:..." example is bogus, as the problem here is apparently the protocol doesn't stream data, but waits for an entire block to be ack'd before continuing; using a larger blocking factor results in better transfer times. -- Jonathan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message