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 |
2 Answers:
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 ♦♦ 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:
(01 May '14, 06:29) Jasper ♦♦ showing 5 of 6 show 1 more comments |
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 answered 01 May '14, 07:18  Kurt Knochner ♦ edited 01 May '14, 07:30 |
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?
I guess the capture files are too large to upload them. If so, can you please add the following screenshots for both capture files?
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)!