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 just tried copying a file over cifs (windows file sharing) between a server 2003 R2 and a new server 2008 SP1 and I'm getting horrible speed.

it's a 300MB file that is taking around 30 minutes to transfer. I'm getting around 1-2Mbit/s and this is on a local switch.

I have tried initiating the transfer from both servers with the same results.

Copying from the 2003 to another 2003 is less than 1 min, so it's obviously something with the 2008-server.

An even weirder behaviour is that if I simultaneously copy another file from the 2003 server to another 2003 server, the transfer rate from the 2008 server increases drastically (like 10x times, but still slow though).

Over RDP-drivesharing I get full VPN-speed, approx 20Mbit. No other services seem to be suffering from any latency.

I have seen post about tcp offloading causing trouble in win2008, could it be related?

share|improve this question

5 Answers 5

up vote 3 down vote accepted

Make sure the 2008 server is working properly on its own. Try tranferring files betweeen it and another 2008 server, or if one isn't available a vista workstation, they use the same cifs version.

I've seen similar file transfer behavior when there was a speed/duplex mismatch between the NIC and the switch, sometimes because of an autosense problem and sometimes because of a misconfiguraton of one or the other, or both.

share|improve this answer
    
Duplex mismatch is a real PITA! Additionally due to lack of good flow control in 100 Meg ethernet (you do not specify if it is GigE or 100 Meg) it can be oddly faster to run your 100 Meg at HALF duplex. Sounds crazy, but really interesting when you test it in the real world! –  geoffc Jul 13 '09 at 1:48
    
I agree verify the servers are not at half duplex and check the switch, crazier things happen. You may need to set it to full duplex. –  Luis Ventura Jul 13 '09 at 3:23
    
This is a ggit NIC connected to a 100Mbit-switch. Both use setting auto, and in my experience duplex mismatch generates far worse performance, aswell as plenty of packetloss which I don't seem to have. –  jishi Jul 13 '09 at 8:33
    
After a few months, I stumbled over a huge error-counter in my switch for this expicit port, and oddly enough my comment about having both set to auto wasn't accurate so it seems. Obviously, an auto-setting against a full duplex setting will revert the auto to half duplex "just to be sure". –  jishi Mar 16 '10 at 9:04

You could try turning off TCP auto-tuning:

netsh interface tcp set global autotuninglevel=disabled

If that doesn't work, turn it back on with:

netsh interface tcp set global autotuninglevel=normal

TCP auto-tuning is a new feature in the Vista and Windows 2008 TCP/IP stack. The amount of data you can send through TCP/IP depends on (among other things) the size of the receive window size. In previous versions of Windows, the receive window size was capped at 64KB. With auto-tuning, the window size is dynamically changed based on the connection's capacity and speed. The idea being that this would speed up data transfers.

The problem is that this feature can actually cause slower transfer rates if the client operating system or network hardware doesn't support this feature correctly (as described in RFC 1323, TCP Extensions for High Performance).

In any case, this may not be the issue here, but it is worth a shot.

share|improve this answer
    
Can you explain WHY that matters? I.e. What does it do, and what might it be doing wrong, that is worth turning it off. –  geoffc Jul 13 '09 at 1:46
    
@geoff - updated the post with a fuller description. –  Adam Brand Jul 13 '09 at 2:31
    
I actually tried this, but no difference. However, I did not reboot the machine after this change, is that necessary? –  jishi Jul 13 '09 at 8:27
    
I don't think a reboot is necessary, but it wouldn't hurt to try. –  Adam Brand Jul 13 '09 at 14:16

People have suggested a few different things in this question: Windows networking performance (SMB/CIFS)

share|improve this answer

My first guess would be a hardware problem. Try using FTP or HTTP to transfer the file and see if that's also slow.

JR

share|improve this answer
    
I'm getting full speed over RDP drive-sharing, which max out at around 20Mbit over the VPN. –  jishi Jul 13 '09 at 8:42

I've just solved a similar problem to this on my network. A Windows 2003 Server machine was getting terrible (~20Kb/s) read speeds from shares on a new Windows 2008 R2 box (but strangely, 2003 >> 2008 was fine, ~50+Mb/s).

Some of the things I tried...

  • Setting autotuninglevel=disabled as suggested above
  • Disabling SMB 2, as described here
  • Tweaking the adapters duplex and flow control settings, mostly based on this post but suggested in a number of places

None of which had any (positive) effect.

For me the solution turned out to be disabling TCP offloading (described here) by adding the following registry keys...

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

Value = DisableTaskOffload
Type = DWORD
Data = 1

Value = EnableTCPChimney
Type = DWORD
Data = 0

Value = EnableTCPA
Type = DWORD
Data = 0

Value = EnableRSS
Type = DWORD
Data = 0

After a restart all transfers were up to speed.

From my (limited) understanding of the problem it only occurs with certain NIC models (mines a Intel 82578DC) in a box running 2008 or Win 7 that's talking to a box running 2003 or XP. In my case the 2003 box was a virtual machine running on VMware Server 2.0.2 (but I don't know if that's relevant).

Hope that helps someone!

share|improve this answer

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.