lkml.org 
[lkml]   [2005]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: Possible BUG in IPv4 TCP window handling, all recent 2.4.x/2.6.x kernels
Hello!

> This is where things start going bad. The window starts shrinking from
> 15340 all the way down to 2355 over the course of 0.3 seconds. Notice the
> many duplicate acks that serve no purpose

These are not duplicate, TCP_NODELAY sender just starts flooding
tiny segments, and those are normal ACKs acking those segments, note
ACK field is not the same.

> Five minutes later the TCP window is still at 2355,
....
> We are kind of stumped at this point, and it's proving to be a
> show-stopping bug for our purposes, especially over WAN links that have
> higher latency (for obvious reasons). Any kind of assistance would be
> greatly appreciated.

I still do not know how the value of 184 is possible in your case,
I would expect 730 as an absolute possible minumum. I see 9420 (2355*4).
Anyway, ignoring this puzzle, the following patch for 2.4 should help.


--- net/ipv4/tcp_input.c.orig 2003-02-20 20:38:39.000000000 +0300
+++ net/ipv4/tcp_input.c 2005-09-02 22:28:00.845952888 +0400
@@ -343,8 +343,6 @@
app_win -= tp->ack.rcv_mss;
app_win = max(app_win, 2U*tp->advmss);

- if (!ofo_win)
- tp->window_clamp = min(tp->window_clamp, app_win);
tp->rcv_ssthresh = min(tp->window_clamp, 2U*tp->advmss);
}
}

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-09-02 20:39    [W:0.293 / U:0.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site