Date: Sat, 24 Feb 2001 14:27:42 -0600 From: Jonathan Lemon <jlemon@flugsvamp.com> To: Mark Peek <mark@whistle.com> Cc: Paul Herman <pherman@frenchfries.net>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu>, Jonathan Lemon <jlemon@flugsvamp.com>, net@FreeBSD.ORG Subject: Re: I have delayed ACK problems Message-ID: <20010224142742.T5714@prism.flugsvamp.com> In-Reply-To: <p05100104b6bdb7b22391@[10.1.10.113]> References: <Pine.BSF.4.32.0101252250480.10921-100000@husten.security.at12.de> <p05100104b6bdb7b22391@[10.1.10.113]>
next in thread | previous in thread | raw e-mail | index | archive | help
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: > > > >> <<On Thu, 25 Jan 2001 11:14:03 -0600 (CST), Jonathan Lemon > >><jlemon@flugsvamp.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010224142742.T5714>