From: Martin Josefsson <hidden> Date: 2003-06-03 17:27:46
(trimmed CC line and added netdev)
On Tue, 2003-06-03 at 17:52, David Mosberger wrote:
One of those very-hard-to-track-down, trivial-to-fix kind of problems:
without this patch, TCP roundtrip time measurements will corrupt the
routing cache's RTT estimates under heavy network load (the bug causes
RTAX_RTT to go negative, but since its type is u32, you end up with a
huge positive value...). From there on, later TCP connections quickly
will go south.
The typo was introduced 8 months ago in v1.29 of the file by the patch
entitled "Cleanup DST metrics and abstrct MSS/PMTU further".
I tested this patch and it looks like it has cured my mysterious TCP
stalls.
without patch:
cache mtu 1500 rtt 479411ms rttvar 953813ms cwnd 46 advmss 1460
I see that before and during the stall if not using this patch.
(rtt is never above 20ms accoring to ping)
With the patch I see normal rtt and rttvar times.
Havn't seen a stall yet (~30 kernelcompiles with distcc over a sometimes
congested link), will continue testing.
From: David Mosberger <hidden> Date: 2003-06-03 18:32:00
quoted
quoted
quoted
quoted
On 03 Jun 2003 19:41:11 +0200, Martin Josefsson [off-list ref] said:
Martin> (trimmed CC line and added netdev) On Tue, 2003-06-03 at
Martin> 17:52, David Mosberger wrote:
>> One of those very-hard-to-track-down, trivial-to-fix kind of
>> problems: without this patch, TCP roundtrip time measurements
>> will corrupt the routing cache's RTT estimates under heavy
>> network load (the bug causes RTAX_RTT to go negative, but since
>> its type is u32, you end up with a huge positive value...). From
>> there on, later TCP connections quickly will go south.
>> The typo was introduced 8 months ago in v1.29 of the file by the
>> patch entitled "Cleanup DST metrics and abstrct MSS/PMTU
>> further".
Martin> I tested this patch and it looks like it has cured my
Martin> mysterious TCP stalls.
Yes, this sounds reasonable. I wasn't very clear on this point, but
"by going south" I meant that TCP is starting to misbehave. In
particular, you'll likely end up with the kernel aborting ESTABLISHED
TCP connections with extreme prejudice (and in violation of the TCP
protocol), because it thought that it had been unable to communicate
with the remote end for a _very_ long time. The net effect typically
is that you end up with one end having a connection that's in the
ESTABLISHED state and the other end having no trace of that
connection.
--david
From: James Morris <hidden> Date: 2003-06-04 00:12:44
On Tue, 3 Jun 2003, David Mosberger wrote:
Martin> I tested this patch and it looks like it has cured my
Martin> mysterious TCP stalls.
Yes, this sounds reasonable. I wasn't very clear on this point, but
"by going south" I meant that TCP is starting to misbehave. In
particular, you'll likely end up with the kernel aborting ESTABLISHED
TCP connections with extreme prejudice (and in violation of the TCP
protocol), because it thought that it had been unable to communicate
with the remote end for a _very_ long time. The net effect typically
is that you end up with one end having a connection that's in the
ESTABLISHED state and the other end having no trace of that
connection.
David,
This might be the solution to one of the 'must-fix' bugs for the
networking, which nobody so far was quite able to track down.
- James
--
James Morris
[off-list ref]