This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

iperf and 64K window size

0

I did an iperf test across my 200Mb WAN line... I got 50Mb/s

Next I did another iperf test, same source, destination but added -w 64KB... I got 140Mb/s

The obvious answer is that the calculated window size was larger in the second test right? But it wasn't. I capture both iperf runs and both had 64K CALCULATED window size. How is this possible?

asked 29 Apr '14, 13:51

uncleboarder's gravatar image

uncleboarder
1223
accept rate: 0%

Window size is 64K (both directions) for ~99% of the traffic... both captures.

Packet length (iperf 1):
40-79 23%
1280-2559 63% (max packet length captured is 1514)
(all other lengths are less than 1%)

99.99% of capture is 64K calculated WinSize
20,351 total packets

Packet length (iperf 2):
40-79 27%
1280-2559 69% (max packet length captured is 1514)
(all other lenghts are less than 1%)

98.7% of capture is 64K calculated WinSize (only 30 packets are less than 30K)
48,810 total packets

Suggestions?

(01 May '14, 10:34) uncleboarder

I guess the capture files are too large to upload them. If so, can you please add the following screenshots for both capture files?

Statistics -> TCP StreamGraph -> Round Trip Time Graph
Statistics -> TCP StreamGraph -> Window Scaling Graph
Statistics -> TCP StreamGraph -> Throughput Graph
Statistics -> TCP StreamGraph -> Time-Sequence Graph (tcptrace)

Please consider, that these graphs will report different things if you calculate them while a frame from A -> B (e.g. SYN) was selected versus B -> A (e.g. SYN-ACK)!

(01 May '14, 16:13) Kurt Knochner ♦

2 Answers:

0

There is a lot more to TCP throughput than Window Size - it's not a magic bullet to look at the calculated Window size.

Check packet sizes, delta times between packets, delay on the sender side to prepare the next batch, serialization delay, buffering delay etc etc. If one throughput is less than the other find out why by looking at the capture.

answered 29 Apr '14, 13:55

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Packet sizes and delta times are visually similar but I don't know how to make a direct comparison and identify why one is 3 times faster than the other.

This is repeatable. The source, destination, and path are unchanged. The only change I make is using the iperf window size setting (which apparently doesn't change the window size).

What is the iperf setting changing that makes this difference?

I can see one is slower than the other by looking at the capture, but I don't know how to identify why. I've been researching and reading and the best culprit seemed to be window size. But now I'm doubting that answer. Need help in how to identify the cause of the througput difference.

(29 Apr '14, 14:15) uncleboarder

The iperf window size setting does not affect the TCP window size last time I checked, because that is still something the TCP stack of the OS controls. What the setting does is send more or less blocks of data in one go to the TCP stack for transmission, so it's an application level setting.

If you put give the TCP stack more data to transfer it can push it out as fast as possible, without saying less often to the application "ok, this batch was done, give me more", which causes delay.

(29 Apr '14, 14:23) Jasper ♦♦

That would suggest that the application is the bottleneck in this particular test. However the same iperf settings on the same iperf server can deliver around 600Mb/s on my LAN so this doesn't make sense to me.

My goal is to determine why I can't fill my 200Mb (5ms) pipe. At that spec, 200Mb/5ms, I can only have about 100Mb in flight with a 64K window size. So... it's difficult to NOT associate window size since that's a break point for the math. I used iperf to "prove" that it was not a window size problem but perhaps I haven't done that.

I know iperf can deliver a lot faster... around 600Mb/s on my LAN. So how do I determine why a single transfer across my WAN is stuck around 100Mb?

I need a suggestion.

(29 Apr '14, 14:53) uncleboarder
1

Uhm, if it was my test I would read the trace file to see where the delays are...

(29 Apr '14, 14:55) Jasper ♦♦

It seems you have a lot more experience than I do and you think that reading the trace to find delays is an obvious answer. For an average Wireshark user, it is not.

I'm posting here because I've already read/reasearched to my ability level and need help. I can read through the trace. I know delta times look very similar but I don't know how to do a 100% comparison so have I missed something? I don't know. I can see that packet size distribution is very similar by visually scanning the trace files. And I don't know how to check the delays that you mentioned. (batch prep, serialization, buffering).

Can I get a little more help than "read the trace file".

(01 May '14, 05:40) uncleboarder

okay, two options:

  1. try doing ftp transfers instead of iperf and measure throughput using Wireshark, e.g. by leveraging the conversation statistics/TCP tab. Ftp sends all data in one go, so its usually good for testing throughput

  2. put your iperf captures up at http://www.cloudshark.org so I/we can take a look and give you more detailed feedback.

(01 May '14, 06:29) Jasper ♦♦
showing 5 of 6 show 1 more comments

0

and both had 64K CALCULATED window size. How is this possible?

There is a Window size for both directions of the connection. Are you sure you were checking the correct window size? Additionally I have noticed that iperf options sometimes behave differently than one might expect (depends on the OS).

Regards
Kurt

answered 01 May '14, 07:18

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 01 May '14, 07:30