Ok, there's packet loss. From this extract you can see
that the client receives through sequence 641, then the
next packet it receives starts at sequence 993.
15:28:09.879928 transwarp.tao.org.uk.telnet > genius.tao.org.uk.kpop: P 609:641(32)
ack 64 win 33304 <nop,nop,timestamp 152269835 86
8399> (DF) [tos 0x10]
15:28:09.881926 transwarp.tao.org.uk.telnet > genius.tao.org.uk.kpop: P 993:1025(32)
ack 64 win 33304 <nop,nop,timestamp 152269835 8
68402> (DF) [tos 0x10]
If you look at the server you can see the (tiny) packets
being transmitted:
15:28:18.255648 transwarp.telnet > genius.kpop: P 609:641(32) ack 64 win 33304
<nop,nop,timestamp 152269835 868399> (DF) [tos 0x10]
15:28:18.255775 transwarp.telnet > genius.kpop: P 641:673(32) ack 64 win 33304
<nop,nop,timestamp 152269835 868399> (DF) [tos 0x10]
15:28:18.255864 genius.kpop > transwarp.telnet: . ack 97 win 33288 <nop,nop,timestamp
868402 152269835> (DF) [tos 0x10]
15:28:18.255955 transwarp.telnet > genius.kpop: P 673:705(32) ack 64 win 33304
<nop,nop,timestamp 152269835 868402> (DF) [tos 0x10]
15:28:18.256084 transwarp.telnet > genius.kpop: P 705:737(32) ack 64 win 33304
<nop,nop,timestamp 152269835 868402> (DF) [tos 0x10]
15:28:18.256223 transwarp.telnet > genius.kpop: P 737:769(32) ack 64 win 33304
<nop,nop,timestamp 152269835 868402> (DF) [tos 0x10]
15:28:18.256351 transwarp.telnet > genius.kpop: P 769:801(32) ack 64 win 33304
<nop,nop,timestamp 152269835 868402> (DF) [tos 0x10]
15:28:18.256479 transwarp.telnet > genius.kpop: P 801:833(32) ack 64 win 33304
<nop,nop,timestamp 152269835 868402> (DF) [tos 0x10]
15:28:18.256607 transwarp.telnet > genius.kpop: P 833:865(32) ack 64 win 33304
<nop,nop,timestamp 152269835 868402> (DF) [tos 0x10]
15:28:18.256734 transwarp.telnet > genius.kpop: P 865:897(32) ack 64 win 33304
<nop,nop,timestamp 152269835 868402> (DF) [tos 0x10]
15:28:18.256884 transwarp.telnet > genius.kpop: P 897:929(32) ack 64 win 33304
<nop,nop,timestamp 152269835 868402> (DF) [tos 0x10]
15:28:18.257011 transwarp.telnet > genius.kpop: P 929:961(32) ack 64 win 33304
<nop,nop,timestamp 152269835 868402> (DF) [tos 0x10]
15:28:18.257138 transwarp.telnet > genius.kpop: P 961:993(32) ack 64 win 33304
<nop,nop,timestamp 152269835 868402> (DF) [tos 0x10]
15:28:18.258068 transwarp.telnet > genius.kpop: P 993:1025(32) ack 64 win 33304
<nop,nop,timestamp 152269835 868402> (DF) [tos 0x10]
15:28:18.258221 transwarp.telnet > genius.kpop: P 1025:1057(32) ack 64 win 33304
<nop,nop,timestamp 152269835 868402> (DF) [tos 0x10
The first one is through 641. The server then sends 11 packets
(641 through 993) that the client misses completely. The
next packet the client sees is the 993:1025 packet.
So there is nothing wrong with the TCP protocol. The question
now is whether this is packet loss due to the physical layer
or whether it is a queueing problem. What kind of network
cards do these machines have and what kind of switching
infrastructure is between them?
One thing that doesn't make sense is that the client
is responding to each packet with its own ack but
the server doesn't see the acks until it finishes
transmitting a big stream of data packets. This
implies half-duplex operation.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
