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
> >><[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
