Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've got a server named Babylon. It's running Windows Server 2003 SP2 and lives in the midwest.

I can ping Babylon from remote machines in the same building by hostname and IP. The latency is <20ms.

I can ping Babylon from machines in another state by hostname and IP. The latency is about 200ms.

I can remote into Babylon from machines in the building and other states and it works fine. Low latency, responsive, fast.

Once I’ve remoted into Babylon, I can copy files locally quickly.

Attempting to connect to a share via UNC (\babylon\projects) and browse the file system is deathly slow. Latency in the dozens of seconds.

Attempting to xcopy a file from one of those shares is deathly slow. Latency in the tens of seconds.

The shares reside on a RAID array. Two 2GB fiber channels for the RAID. I’ve tried it with other shares on the machine. The network utilization never spikes about 0.5%. The CPU usage never spikes above about 1%.

Any ideas what I should be looking at to understand why remote desktop, ping, and local copies are fast and copies across a file share are slow?

share|improve this question
A ping of <20ms from within the same building isn't fast. It should be 1ms if both Babylon and the remote machines in the same building are on the same LAN. – George Tasioulis Sep 28 '11 at 22:54
Sorry - I'll clarify that. The 20ms ping was with a packet size of 65500 bytes. With the default packet size, it's 1ms. – Bill Carey Sep 29 '11 at 12:42

What could cause this is the design of the SMB protocol.

SMB requires a lot of acknowledgemenst, in some case between every single operation. This requirement for lots of acknowledgements means that your latency will kill your performance. It is block based instead of stream based.


share|improve this answer
Zoredache is correct. SMB/CIFS simply sucks over WAN links. – mfinni Sep 28 '11 at 23:01
Would SMB requests saturate the network link with acknowledgments? Even when the server is totally unloaded, listing a directory takes multiple seconds; the network utilization never even hits 1%. – Bill Carey Sep 29 '11 at 12:47

When you open the local area connection properties window, what's the value of Speed on the Babylon server? enter image description here

Can you got to the Device Manager, find your network adapter, go to Properties and make sure that the network adapter's Link Speed & Duplex is set to Auto (or better yet if you know your max speed (eg. 1Gbps) set it to 1Gbps / Full Duplex)?

Have you tried changing to another port on the switch?

Just to be clear: the file copy operations you're trying to do, are between two machines (Babylon & another) on the same LAN, or between Babylon and a remote machine via Internet?

share|improve this answer
The copies are between babylon and another machine on the same LAN. (Copies to a machine on the WAN are even slower). – Bill Carey Sep 29 '11 at 12:40
Too, the network adapter's speed is set at 1Gbps. We've tried changing to another port on the switch, no effect. – Bill Carey Sep 29 '11 at 12:41
Is your nic's chipset from Broadcom? – George Tasioulis Sep 29 '11 at 13:06
If yes: read :-) – George Tasioulis Sep 29 '11 at 13:14
Sadly, we've got Intel NICs in the machine. Amusing story though! – Bill Carey Sep 29 '11 at 13:37

Zoredache answer is correct; and it also means that the network link does not need to be saturated. For some operations (it seems badly buffered I/O) the effective transfer size can even be reduced by a tenfold, compared to normal copy operations.

Imagine a pizza delivery boy that has to drive 15 minutes (latency) to his customer. He has a box that can contain 10 pizza's (bandwidth). But his protocol (SMB) allows to carry only one pizza a time for a client. So if the client orders 5 pizza's, it takes 75 minutes to bring them all.

share|improve this answer

Your Answer


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.