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?

score 3 · Accepted Answer · answered Jul 13 '09 at 00:31

3

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.

answered Jul 13 '09 at 00:31

Leroy Clark

366
2
5

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 01: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 03: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 08: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 09:04

Adam Brand · Answer 2 · 2009-07-13T02:30:59.063

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.

edited Jul 13 '09 at 02:30

answered Jul 12 '09 at 23:17

Adam Brand

6,127
2
30
40

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

score 1 · Answer 3 · edited Apr 13 '17 at 12:14

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!

score 0 · Answer 4 · edited Apr 13 '17 at 12:14

0

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

edited Apr 13 '17 at 12:14

Community

1

answered Jul 13 '09 at 01:25

Luke Quinane

717
1
9
20

score 0 · Answer 5 · answered Jul 13 '09 at 07:46

0

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

answered Jul 13 '09 at 07:46

John Rennie

7,776
1
23
35

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

server 2008 to 2003 slow filetransfer using cifs

5 Answers5