Leave a Comment:
Looks like a delay in ACKs from the client to the server.Reply
When I say client, I’m talking about the host that initiated the connection. In this case with iperf, the client is the one sending data. So when I say the delay is on the client side, I mean the side sending data. See Chris’ comment below on the cause of the slowness. You are correct in that the delay before the ACK is the delay, but that delay is caused by the sender’s (client) too small send buffer for the BDP of the connection. I’ll go into more depth in a future post.Reply
In the iperf capture, 10.2.0.1 has a too-small transmit buffer (64KB-ish) to make good use of this long (90ms), fat (ACKs are rolling in at 9MB/s!) path.
Increasing the send window will help until you hit 220.127.116.11’s receive window 500KB-ish. You should be able to get up to around 5MB/s with changes to the send window only.
Ever use tcptrace and xplot? Sooo much better than visualization in wireshark. It’s the best tool for this work in my opinion.Reply
> Now, can you tell me why Win7 isn’t dynamically increasing
> it as my research suggests that it should? Because damned
> if I can figure out why.
10.2.0.1 understands window scaling, but sent a bone-headed scaling factor of zero.
Now, that’s on the receive side, but maybe there’s something equally stupid going on with the send side that we can’t see on the wire?Reply
[…] tell you that you can prove it and I gave you one example of when it’s not the network in the last video. Now I’m gonna show you a couple […]Reply
Great explanation.. I just started to learn packet analyze and this is a great video!
I realize this is an old post. When I sort by Delta Time I see the large lags in ACK delays from 18.104.22.168 to 10.2.0.1
I just haven’t been able to decipher exactly what your’re pointing to as the cause and where in Wireshark that can be viewed.
Am I correct is saying 10.2.0.1 is what this discussion is calling “the client” some confusion with that. It looks like data is mostly going from 10.2.0.1 to 22.214.171.124
So I’d say 126.96.36.199 is the server and we’re waiting on the server. But I know that’s not what the answer is by reading above. Can somebody clarify?Reply
I think I worked out my own question after digging around…..I guess if anybody wants to still reply I’d happily read it.Reply
Oh that’s okay. I finally understood the explanation. Thanks for the very useful posts/videos. Much appreciated. I hadn’t seen your site before.Reply
mentioned video in this thread is lost…it would be nice if you could add those 2 videos back or guide from where i can get itReply
I’m hoping I can gets some support with reference Wireshark vs. using Netscout Infinistream nGeniousOne, etc.
The organization I work for has recently forced the few hard core and dedicated transaction analysis people using Wireshark to remove wireshark. I would in a huge network enterprise and use wireshark to evaluate how well service and application are functioning once deployed into the production network. I also use it to help end-users and service managers that cannot get their issues addressed via normal ITSM/ITIL ticketing.
In a nutshell all I have left is a locked down Netscout suite disrobed across the US. I can capture packets but the needed context cannot not be obtain, such as where ‘exactly’ logically or physically the packet capture points are. Plus, knowing where to follow a users traffic flows through IP natting where many staffers are teleworking is another pain. I used to act as the ‘typical’ end user by capturing traffic from a science and technology machine using wireshark. This allowed me to be able to analyze specific transactions for specific applications, etc., as used by the end-user. I could rapidly change the context of analysis. Wireshark has been really useful with analyzing TCP flows.
I’m attempting to convince and describe to the talking heads that Netscout and Wireshark are optimized for vary different purposes. I have lots of specific examples, but I’m hoping someone out there can provide some industry level authoritative – this is how the real world works. THANKS IN ADVANCE W/RFritz
Hi Kary – great post. Reading packet captures is always something I wish I had a better understanding of. From what I can see it looks like the delay is on the client side.Reply