On Sat, Dec 29, 2001 at 10:44:31PM -0800, Matthew Dillon wrote: > > 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?
No switching infrastructure. It's a 10mb/s half duplex ethernet network, with two hubs between the two machines. > 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. Yes, it is half-duplex. Joe
msg30559/pgp00000.pgp
Description: PGP signature
