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?

5 Answers 5


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.

  • 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, 2009 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. Jul 13, 2009 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, 2009 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, 2010 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.

  • 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, 2009 at 1:46
  • @geoff - updated the post with a fuller description.
    – Adam Brand
    Jul 13, 2009 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, 2009 at 8:27
  • I don't think a reboot is necessary, but it wouldn't hurt to try.
    – Adam Brand
    Jul 13, 2009 at 14:16

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


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!


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


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


  • I'm getting full speed over RDP drive-sharing, which max out at around 20Mbit over the VPN.
    – jishi
    Jul 13, 2009 at 8:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.