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 have a desktop computer with two SSD's in RAID 0 with a read/write speed of 950 MB/sec (7.6 Gbps) and I have a server with 6 HDD's in RAID 5 (read/write speeds of 200 MB/sec or 1.6 Gbps) acting as a file server. Currently, both my server and my desktop are plugged into a Gigabit switch which is plugged into a Gigabit Cisco Router. I am using all CAT 6 cable for everything, my server and my desktop have Gigabit Ethernet cards in them, and nothing is happening on the server or on the desktop. When I try to copy a large file from my desktop to my server I reach a bottleneck of about 54 MB/sec (432 Mbps). What could possibly be the bottleneck that would be slowing this down? Both NIC's are not even 50% utilized.

Server OS: Windows Server 2008 R2 Standard Desktop OS: Windows 7 Ultimate

share|improve this question
you're using the wrong tool to benchmark. Try netcat to measure max network speed possible. Then find a program that can work with less overhead than windows file sharing. Network tuning like increasing buffers and large frames can also help. – akostadinov Oct 10 '12 at 7:38

For large files, the effective performance of Windows file sharing is around 50% of the expected bottleneck bandwidth. That's what I found when doing controlled benchmarks of various file transfer methods on Windows NT 4.0 many years ago. I found Windows FTP to be much faster, same for Cygwin FTP and SCP. My impression is that this has not changed up to Windows 7. Looks like the underutilization is built into the protocol, maybe it plays ping-pong.

One of the parameters that I had needed to tune (increase) in order to achieve near "bottleneck performance" with FTP back then was the TCP window size. However, I expect the default value to have been increased since then. Since buffering parameters like this affect more than throughput, be careful when touching them.

share|improve this answer
It's a combination of two factors: 1) A remote file system will never perform the way a file transfer protocol does because it has a much more complex job. It can't accurately predict what the other side is going to request. 2) Typical windows programs don't issue requests that are efficient for remote file systems because they aren't made to. A program issues a read request and then it won't issue another read request until you give it every byte of data from the previous one. This forces turnarounds and latencies into the protocol. – David Schwartz Oct 10 '12 at 11:30
That's what I meant by "playing ping-pong" - when you play with only one ball, you have to wait until the other side plays it back. :) – Rainer Blome Oct 11 '12 at 14:09

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.