Leave a Comment:
(14) comments
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 
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 1.2.3.4’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 Kary,
> 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!
Thanks Kary.
I realize this is an old post. When I sort by Delta Time I see the large lags in ACK delays from 1.2.3.4 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 1.2.3.4
So I’d say 1.2.3.4 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