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

We have two servers in different data centers which are geographically separated by several hundred miles. The RTT (round trip time) for a ping between them is 61ms over our VPN. Both servers are on a gigabit WAN link.

Any type of file copy, whether SMB (drag and drop), FTP (tried FileZilla, TFTP, etc.) is excruciatingly slow, at around 1 Mbps. I've tried enabling and disabling Receive Window Auto-Tuning Level, multithreaded copy, and so forth. Our firewalls have lots of CPU headroom, so VPN encryption doesn't play a factor.

I thought about manually setting the TCP window size because it seems like an obvious candidate here but my understanding is that Windows Server 2008 R2 ignores any custom TcpWindowSize setting in the registry.

Update: TCP Window Sizes appear to be fine. Wireshark shows Window Size 513 with a Window Size Scaling Factor of 256 for a Calculated Window Size of 131328. Does this sound right? Bytes in flight stays at around 9000 bytes during an ongoing FTP transfer.

share|improve this question
    
The actual WAN link with the ISP is really gigabit on both sides? –  TheCleaner Nov 16 '12 at 19:22
    
Yes. We have a 100 Mbit commit on both sides, burstable to 1000 Mbit. –  AX1 Nov 16 '12 at 19:24
1  
Try iperf between them, then get with the ISPs and find out where the bottleneck is. Doesn't sound like the servers themselves. Is the connection a VPN tunnel where you can test throughput between a server and another outside host (like miranda or similar) –  TheCleaner Nov 16 '12 at 19:31
    
any qos being applied? –  tony roth Nov 16 '12 at 21:18
    
No QoS configured. –  AX1 Nov 16 '12 at 21:50
show 1 more comment

2 Answers 2

One thing to consider is that many of these transfers are very chatty. This means that there is a great deal of back and forth chatter for a file transfer. We had this same issue and found that the bigger pipe did not help as there was so much overhead.

There is no way to make all that communication go faster than light and since there is so many back and forth trips, the larger pipe often does not help. You may want to look at a WAN accelerator. For our issues with SharePoint and a CRM at sites in several cities, the difference was startling.

I am not suggesting a specific product but simply a place to look for technical info. We looked at many different products and finally settled on Riverbed Steelhead devices. We installed trial units in three sites and the help desk calls stopped almost immediately. You can easily see the difference using the web based GUI and one the web traffic for SharePoint we were reducing traffic by up to 90% so we improved speed and reduced traffic which reduced costs. Since we could not even get faster connections at several sites, this was a great solution.

Riverbed suggest an acceleration of 5-50 times and we exceeded in some cases. They have a great deal of technical info on the issue you have encountered that I think will help more than I can put here Riverbed Steelhead

share|improve this answer
    
I agree that the chattiness is an issue, especially with SMB if each small block has to be acknowledged (hence my comment on TCP window size). See above for my Wireshark update... –  AX1 Nov 16 '12 at 20:24
    
I can only say that we tried many "tweaks" to the various links and none made a significant difference due to the number of back and forth trips SharePoint and the CRM used. Other apps were also imapcted but did not cause as much grief as they were not as critical. –  Dave M Nov 16 '12 at 21:37
add comment
  1. Slam them with a simple run of netcat -- a stream of random data that is discarded on teh other end. I know there's a Windows version out there somewhere. Use that as a baseline.

  2. If that doesn't receive a full speed run, sniff your connection and do it again. Look for packet loss, out of order receipts, bad checksums, etc.

  3. Isolate the problem. Run netcat internally to both networks. Run it from your border, replacing the router. Continue unti you know where the problem is or you can tell your ISP the problem is somewhere in the link between site with details about how the problem presents itself.

share|improve this answer
add comment

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.