Aaron Allen wrote:
My attachments were a bit too large, I have put the attachments referenced below up at this site temporarily:
http://216.248.62.108/wireshark/
Sake,
Sorry, to be more clear:
Windows 2008 -> Amazon (this is where I'm seeing problems) Vista Workstation -> Amazon (I consistently get 8-10mbit)
I've attached local and SPAN packet captures from two uploads to S3. The "largewindow" captures are from the Vista workstation and the "smallwindow" captures are from the windows 2008 server.
The NIC in the server is an Intel Pro 1000 MT and I have disabled "Large Send Offload" (which is intel slang for TCP segmentation offloading). Of course, drivers are updated.
Hansang,
I see what you are talking about when I look at the TCP graphs. Netstat -t is showing the connections in state "InHost" which would eliminate the possibility of offload problems (I assume?).
I'll admit, I'm confused. I see larger window sizes in the packet captures from the Vista workstation, but not from the Windows 2008 server. The packet captures from the local and SPAN session vary greatly from the Vista machine. Since that NIC has "Large Send Offload" enabled, I'm guessing the workstation NIC is handling segmentation, and thus the differences.
Is it possible that this is an application limitation? I really thought this should all be transparent to the app.
Thanks for all your help!
OK, I think I know what's going on. There is actually a lot going on in
this trace. For example, you are seeing some congestion as the
syn/syn+ack is 70ms, but some ACKs come back in 11ms.
But the key thing here is the 8192 byte sending buffer by the
application. Clearly TCP is not at fault here. But then someone in my
team noticed something. You are doing a PUT from IE correct?
See: http://support.microsoft.com/kb/329781
The PUT default sending buffer (not to be confused to TCP send buffer)
defaults to 8192 bytes.
Let us know if that fixes it.
--
Thanks,
Hansang