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.

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
2  
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
add comment

1 Answer

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
1  
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
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.