> The same material is being requested/transferred in both dumps. The server
> was running on host-210 [server] port 3000. Again the client was running
> on NT4.
2.0dump.txt:
11.322331 client.1712 > server.3000: S 28535263:28535263(0) win 8192 <mss 1460> (DF) [tos 0x10]
11.332331 server.3000 > client.1712: S 1672595640:1672595640(0) ack 28535264 win 32736 <mss 1460>
11.332331 client.1712 > server.3000: . ack 1 win 8760 (DF) [tos 0x10]
11.332331 client.1712 > server.3000: P 1:36(35) ack 1 win 8760 (DF) [tos 0x10]
11.342331 server.3000 > client.1712: P 1:157(156) ack 36 win 32736 (DF) [tos 0x10]
11.342331 server.3000 > client.1712: . 157:1617(1460) ack 36 win 32736 (DF) [tos 0x10]
11.342331 client.1712 > server.3000: . ack 1617 win 8760 (DF) [tos 0x10]
11.342331 server.3000 > client.1712: . 1617:3077(1460) ack 36 win 32736 [tos 0x10]
11.342331 server.3000 > client.1712: P 3077:4075(998) ack 36 win 32736 (DF) [tos 0x10]
11.342331 server.3000 > client.1712: F 4075:4075(0) ack 36 win 32736 [tos 0x10]
11.342331 client.1712 > server.3000: . ack 4076 win 8760 (DF) [tos 0x10]
11.342331 client.1712 > server.3000: F 36:36(0) ack 4076 win 8760 (DF) [tos 0x10]
11.342331 server.3000 > client.1712: . ack 37 win 32735 (DF) [tos 0x10]
Note the 10 ms delay after the server has received 1:36, but waits to send
an ACK until the application has some data to return. After only 10 ms it
manages to send both the ack 36 and some new data 1:157, to which the NT
client immediately responds. Speculation: 2.0 should not have sent out
two outstanding segments at the beginning of slow start, but NT sees them
and must ACK immediately.
2.2dump.txt:
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]
13.959084 client.1582 > server.3000: P 1:36(35) ack 1 win 8760 (DF) [tos 0x10]
13.959154 server.3000 > client.1582: . ack 36 win 32120 (DF)
14.008709 server.3000 > client.1582: P 1:157(156) ack 36 win 32120 (DF)
14.151263 client.1582 > server.3000: . ack 157 win 8604 (DF) [tos 0x10]
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]
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]
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)
Here the 2.2 server immediately acks for 1:36, then this time the app takes
50 ms to generate (maybe) and return the data. Apparently the NT box has
gotten distracted, and takes 142 ms to notice and continue the conversation.
Speculation: NT is doing delayed ack, and hoping for some data, hits the
timeout, and ACKs.
Mark: can you narrow down these thousand line tracefiles into something
just like #42 above that obviously shows the differences, just to make sure
I'm not mistaken and there's no interaction across the conversations? And
find out if it's really the app that's taking 50 ms vs 10 ms to generate
the data, or if that's TCP's problem. Also you could check to see if the
NT timeout in the 2.2 dump is always in the range 0--200 ms to confirm the
delayed ack theory.
-- Pete
---------------------------------------------
Pete Wyckoff | wyckoff@ca.sandia.gov
Sandia National Labs | 925 294 3503 (voice)
MS 9011, P.O. Box 969 | 925 294 1225 (fax)
Livermore, CA 94551 |
-
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/