netdev
[Top] [All Lists]

Re: 2.6.10 TCP troubles -- suggested patch

To: Rick Jones <rick.jones2@xxxxxx>
Subject: Re: 2.6.10 TCP troubles -- suggested patch
From: Nivedita Singhvi <niv@xxxxxxxxxx>
Date: Fri, 11 Feb 2005 15:09:11 -0800
Cc: Hubert Tonneau <hubert.tonneau@xxxxxxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, shemminger@xxxxxxxx, romieu@xxxxxxxxxxxxx, kuznet@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <420D37A3.6020209@xxxxxx>
References: <0525M9211@xxxxxxxxxxxxxxxxxxxxx> <420D37A3.6020209@xxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217
Rick Jones wrote:

000010 10.107.96.7.32801 > 10.107.96.230.139: . 11692:13140(1448) ack 822 win 1460 <nop,nop,timestamp 534449 1709240658> NBT Packet (DF) 000004 10.107.96.7.32801 > 10.107.96.230.139: . 13140:14588(1448) ack 822 win 1460 <nop,nop,timestamp 534449 1709240658> NBT Packet (DF) 000002 10.107.96.7.32801 > 10.107.96.230.139: P 14588:16036(1448) ack 822 win 1460 <nop,nop,timestamp 534449 1709240658> NBT Packet (DF) 000022 10.107.96.7.32801 > 10.107.96.230.139: . 16036:17484(1448) ack 822 win 1460 <nop,nop,timestamp 534449 1709240658> NBT Packet (DF) 000004 10.107.96.7.32801 > 10.107.96.230.139: P 17484:18192(708) ack 822 win 1460 <nop,nop,timestamp 534449 1709240658> NBT Packet (DF) 000994 10.107.96.230.139 > 10.107.96.7.32801: . ack 18192 win 65535 <nop,nop,timestamp 1709240658 534449> (DF)
0

And then other cases where the ACK seems to take a rather long time to arrive, seems to correlate a bit with slowly increasing numbers of segments before the ACK is sent, and something along the lines of a 200 millisecond delayed ACK timer.

In some cases at least if the sender does not completely fill cwnd the ACKs will be delayed. And IIRC under 2.6.10 with TSO enabled, the sender does not always fill cwnd.

Er, how is this compliant with 2581 (yes, I know, it's only
a SHOULD, not a MUST)  - an ACK should be generated for at
least every second full-sized segment received? Don't see
that happening. In many cases it's receiving quite a few
more packets. It should not be waiting for the delayed
ack timer to go off, surely?

thanks,
Nivedita


<Prev in Thread] Current Thread [Next in Thread>