Date: Sat, 24 Feb 2001 11:19:02 -0800 From: Mark Peek <mark@whistle.com> To: Paul Herman <pherman@frenchfries.net>, Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Jonathan Lemon <jlemon@flugsvamp.com>, <net@FreeBSD.ORG> Subject: Re: I have delayed ACK problems Message-ID: <p05100104b6bdb7b22391@[10.1.10.113]> In-Reply-To: <Pine.BSF.4.32.0101252250480.10921-100000@husten.security.at12.de> References: <Pine.BSF.4.32.0101252250480.10921-100000@husten.security.at12.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Thanks,
Mark
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?p05100104b6bdb7b22391>