server 2008 to 2003 slow filetransfer using cifs

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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!

Answer 4

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

Answer 5

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