Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I do a ton of uploading to S3 and am experiencing capped speeds and I can't quite figure out how to address it.

The setup: Windows Server 2008 R2 x64, external HD, using a Java based upload tool called Jsh3ll and custom VBS scripts to kick the jobs off.

Running one process at a time, I am always limited to about 4mbps. I have FiOS at 35/35mbps speeds, so it isn't an outright limit. AND, I can run parallel instances and can go all the way up to 35mbps, so I know the problem isn't gateway/nic/machine/amazon related. Running parallel instances works to a degree as a solution, but increases the complexity of my workflow greatly. Solving this would make my life dramatically easier.

When I was first doing this I was playing around with a bunch of Windows TCP parameters and was able to briefly get unconstrained bandwidth, but it wasn't repeatable.

Thoughts?

share|improve this question

1 Answer 1

I strongly suspect you're seeing a bandwidth-delay product (BDP) artifact. A "long, fat pipe" (high bandwidth, high latency) limits the amount of data that TCP can put "in flight" at any given time. Your observation that parallel transfers run faster is a big indicator of BDP coming into play.

What's your round trip latency to S3 look like?

You might try enabling the Compound TCP Congestion Provider (CTCP) via the netsh interface tcp set global congestionprovider=ctcp command. This congestion provider is supposed to "aggressively" set the send window to put more data "in flight" on high bandwidth, high latency networks.

From the Microsoft Research paper:

For TCP connections with a large TCP Receive Window size and a large bandwidth-delay product (the bandwidth multiplied by the latency of the connection), Compound TCP (CTCP) in the Next-Generation TCP/IP stack aggressively increases the amount of data sent at one time ... In testing performed internally at Microsoft, large file backup times were reduced by almost half for a 1 Gigabit-per-second connection with a 50-millisecond round-trip time. Connections with a larger bandwidth-delay product can have even better performance.
share|improve this answer
    
Sorry for the delay in responding, I wanted to make sure I had a reboot and was able to test under the same conditions. It appears that this hasn't yet solved my problem. What else can I check? Tracert to S3 doesn't give me the full latency picture, but up to level3 in WA, I'm sub 30 ms. –  CoreyH May 25 '10 at 2:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.