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>