Thanks for the analysis.
I am on a simple switch, no VLAN, nothing. Maybe it is capturing in both directions? I assume there is some way to filter that when capturing.
Anyway, I am seeing better response since I moved the machine directly next to the switch (I was initially suspicious of the segments as being problematic). But it is good to see other physical limits (not the network itself) as being problematic.
-Scott
----- Original Message -----
Date: Sun, 28 Dec 2008 19:17:21 +0100
From: Sake Blok <sake@xxxxxxxxxx>
Subject: Re: [Wireshark-users] Need help analyzing...
To: Community support list for Wireshark
<wireshark-users@xxxxxxxxxxxxx>
Message-ID: <20081228181721.GA25308@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii
On Sun, Dec 28, 2008 at 08:47:10AM -0500, Scott Chapman wrote:
> Please take a look at the log file attached and let me know what you
> think. I see a lot of TCP out of order. Is that an issue I should be
> worried about?
Nope, the out-of-order messages are all duplicate packets. Did you span
a vlan on the switch? Did you capture both directions? Every packet will
enter AND leave the vlan, hence duplicate packets. If you span a vlan,
you'd better use only one direction instead of both.
You can remove the duplicate packets from the tracefile with:
editcap -d <infle> <outfile>
I have looked at the resulting file and see that the two systems
communicate at 200Mbit/s, which is better than the 10MB/s you were
mentioning, but still not the speed you might expect. Part of this is
due to the nature of Windows file sharing (it transmits blocks of data
instead of streaming the data). But I think the main factor is that the
fileserver (192.168.1.95) is not keeping up with the data. In frame 52
(from the deduplicated file), the window size drops to 0, which means
the server says it is not capable of receiving more data, since the
buffers are filled up and the tcp stack waits for the application layer
to process the data.
Hope this helps,
Cheers,
Sake
