Hello again, Since the last round of posts, I have rejigged my test setup and started using Wireshark to snoop on the network traffic between my laptop client and the server.
The two are now connected directly via Gigabit ethernet cable without any intervening switches. I have also tried another cable just in case - no difference. The client and server IPs are 192.168.0.67 and 192.168.0.100 respectively. As before I am using Iperf to generate traffic and measure the bandwidth. I also have a SSH session open. I start Wireshark on the client and and invoke the test (also on the client). This sends roughly 1MB of data to the server. aeon:~ andrewharvey$ iperf -c 192.168.0.100 -fM -t.05 ------------------------------------------------------------ Client connecting to 192.168.0.100, TCP port 5001 TCP window size: 0.13 MByte (default) ------------------------------------------------------------ [ 3] local 192.168.0.67 port 53160 connected with 192.168.0.100 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 0.1 sec 0.94 MBytes 18.7 MBytes/sec As soon as the test ends I stop capturing. The resulting log file is attached to this message. The results are interesting... First of all, Wireshark flags all the packets sent from the client as having the wrong header checksum. This is because checksumming is offloaded onto hardware, and Wireshark is intercepting the outgoing packets before they get there. So we can safely ignore that issue. However, the server appears to be acknowledging packets that haven't yet being sent: 241 0.030294 192.168.0.67 192.168.0.100 TCP [TCP Previous segment lost] 53160 > commplex-link [PSH, ACK] Seq=310849 Ack=1 Win=524280 Len=472 TSV=382288475 TSER=972369 One possible explanation is that Wireshark simply isn't capturing all the outgoing packets, and every now and then misses a few. Wireshark also reports [TCP Previous segment lost] errors. For example: 364 0.038842 192.168.0.67 192.168.0.100 TCP [TCP Previous segment lost] 53160 > commplex-link [ACK] Seq=507929 Ack=1 Win=524280 Len=1448 TSV=382288475 TSER=972370 This may be related to the above ACK problem. Additional strangeness occurs at the very end after the Iperf test when it attempts to close the connection. In the attached capture there are eight identical [FIN, ACK] packets and nine duplicate ACKS from the server! I would be grateful if someone could give me their informed opinion as to whether there is anything suspicious going on here. Thanks, Andrew -- This message posted from opensolaris.org _______________________________________________ networking-discuss mailing list [email protected]
