lkml.org 
[lkml]   [1999]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: very poor TCP performance with 2.2.2
   Date: 	Thu, 25 Feb 1999 16:24:40 -0800
From: pw@dancer.ca.sandia.gov (Pete Wyckoff)

2.2dump.txt:

I'm going to analyze this trace from the perspective of ACK'ing (at
the receiver) and congestion avoidance (at the sender):

13.957811 client.1582 > server.3000: S 28534252:28534252(0) win 8192 <mss 1460> (DF) [tos 0x10]
13.957907 server.3000 > client.1582: S 1635428655:1635428655(0) ack 28534253 win 32120 <mss 1460> (DF)
13.958224 client.1582 > server.3000: . ack 1 win 8760 (DF) [tos 0x10]

Normal startup, looks fine.

13.959084 client.1582 > server.3000: P 1:36(35) ack 1 win 8760 (DF) [tos 0x10]

First data packet, congestion window should be exactly 1 on the NT box.

13.959154 server.3000 > client.1582: . ack 36 win 32120 (DF)

Ack immediately first data packet, so the sender can begin to leave
slow start (and thus increase his congestion window), his congestion
window should be at 2 when he receives this ack (and thus be allowed
to send two frames).

14.008709 server.3000 > client.1582: P 1:157(156) ack 36 win 32120 (DF)

Sender can send 2 more packets legally (in congestion avoidance terms)
and here is the first one.

14.151263 client.1582 > server.3000: . ack 157 win 8604 (DF) [tos 0x10]

We delay the ACK, because with a congestion window of 2 packets (at
the sender) he should be able to send us two data frames if he has
that much data to send.

Aparently he does not, I think this is a bug in NT.

Since NT is mostly BSD TCP derived I would like to see if people see
this behavior on other BSD TCP's.

14.151353 server.3000 > client.1582: . 157:1617(1460) ack 36 win 32120 (DF)
14.151520 server.3000 > client.1582: . 1617:3077(1460) ack 36 win 32120 (DF)
14.154405 client.1582 > server.3000: . ack 3077 win 8760 (DF) [tos 0x10]

Back to normal behavior, sender pushes 2 full sized frames, and we ack
immediately after the second.

14.154474 server.3000 > client.1582: FP 3077:4075(998) ack 36 win 32120 (DF)
14.155811 client.1582 > server.3000: . ack 4076 win 7762 (DF) [tos 0x10]

We ack the data packet with FIN immediately, because no more data is expected.

14.155971 client.1582 > server.3000: F 36:36(0) ack 4076 win 7762 (DF) [tos 0x10]
14.156026 server.3000 > client.1582: . ack 37 win 32120 (DF)

Client closes too and sends the FIN.

A side note, all the bitching about the bad interactions we have with
Solaris boxes wrt. FIN's, look what NT does here, the same like 2.2.x
by attaching the FIN to the final data frame.

Later,
David S. Miller
davem@redhat.com

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

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.086 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site