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 wrote a program that uses xcopy to transfer files (usually between 1KB and 2MB) over our intranet. Usually, I am copying files from my host machine (Windows 7 x64) to a VMWare virtual machine running Windows Server 2008 (the VM is running on my host machine, if that matters).

On Windows XP, the file transfers usually only require a few seconds to complete. But on my Windows 7 machine, the transfer of the first file (1.5 MB) takes around 1.5 minutes to complete. This is true whether I use xcopy, robocopy, or programmatically using File.Copy(). I noticed that if I use File.Copy, the first transfer is very slow and subsequent transfers are much faster.

Any clue how I can speed up the process? Is there a setting in Windows 7 (or server 2008) that I could try?

share|improve this question

7 Answers 7

Consider turning off Remote Differential Compression as per this article: http://www.windowsreference.com/windows-7/slow-network-file-copy-issues-in-windows-7-caused-by-remote-differential-compression/

EDIT: You can read up on the specifics of Remote Differential Compression here: http://msdn.microsoft.com/en-us/library/aa372948%28VS.85%29.aspx

share|improve this answer
    
hey wesley, i follow you on twitter. coincidence. I tried this but it has no efect. Also tried mnually setting FUll duplex. One thing of note is that my windows 7 has gigabit ethernet connected to gigabit power adapter but the XP is 100 Mbps lan. I am going to try Filezilla ftp solution. sysamdin to rescue. darm i hate windoze –  Vangel Oct 7 '11 at 8:22
    
@Vangel Interesting experience you're having. I totally forgot about this question. Sometimes the fastest solution is better than digging into the 1s and 0s to find the underlying cause. Not often, but sometimes. –  Wesley Oct 7 '11 at 15:54
    
well Filezilla FTP works fine. it delivers the max speed possible like 70Mbps. However I am guessing its the negotiation between windows in the windows ways of doing things is screwed. Still no solution. –  Vangel Oct 13 '11 at 16:41

I found a good lead on another board ( http://social.technet.microsoft.com/Forums/en/w7itpronetworking/thread/c30f6649-a0d9-4f5e-8671-904a8f5469bb ). Since the problem had a lot of leads which didn't work, I thought I'd cross-post a solution that worked for me.

Specifically, my problem was that file transfers FROM Windows 7 to XP were slow, measured by seeing network utilization in the Task Manager at about 1%. Transfers from XP to Windows 7 typically used 80-99% of the network bandwidth. These results were achieved whether the transfer was "push" or "pull".

What worked for me: I went to Local Area Network properties, Configure, Advanced Tab, and disabled Large Send Offload v2. The advice to disable autotuning, RSS, set Speed & Duplex to a specific value, remove from homegroup, did nothing. Ultimately, the settings which worked on my Dell XPS 8100 Windows 7 Pro 64-bit workstation were as follows:

ARP Offload - Enable
Ethernet@WireSpeed -Enable
Flow Control - Auto
Interrupt Modulation - Enable
IPv4 Checksum Offload - Rx & Tx Enabled
Large Send Offload (IPv4) - Enable
Large Send Offload v2 (IPv4) - Disable
Large Send Offload v2 (IPv6) - Disable
Network Address - Not present (radio button)
NS Offload - Enable
Priority & VLAN- Priority & VLAN Enabled
Receive Side Scaling - Enable
RSS Queues - RSS 4 Queues
Speed & Duplex - Auto
TCP & UDP Checksum Offload (IPv4) - Rx & Tx Enabled
TCP & UDP Checksum Offload (IPv6) - Rx & Tx Enabled
VLAN ID - 0 Wake Up Capabilities -
Both WOL Speed - Lowest Speed Advertised

Hope this proves helpful to someone else.

share|improve this answer

This kind of slowness is usually caused by a misbehaving\misconfigured network interface. If the auto negotiation between the network interface and the switch doesn't work properly( and often this is the case) the network interface will use wrong duplex setting. Somehow it allows network traffic to flow but very slowly. Check the NIC configuration and the network port configuration and make sure they are synchronized.

share|improve this answer

For me the issue was segmentation offloading.

The solution from here worked for me... (I know the article states Virtual Server 2005 ; but this fix the issue for me in Virtual PC on Win7) http://support.microsoft.com/kb/888750

Basically on the host computer:

  • Run Registry Editor (regedit.exe) and select the following key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
  • Create new DWORD value named DisableTaskOffload and set its value to 1.
  • Restart the host computer.
share|improve this answer

I had Exactly the same problem

Win7 PCs had a long delay when saving from word or Excel, but XP machines were fine.

The culprit in my case was Immunet Antivirus loaded on my 2008 Server

Uninstalled that and everything was fine.

It seems to be a 3rd party software issue and not Office.

share|improve this answer

Forget RoboCopy, or xcopy, or whatever. Windows7 will allow you to map a drive letter to a FTP service. FTP is fast. Then use NULL FTP Server to run a ftp site on on the remote machine. Also, you can write a DOS script to push/pull files from the location in a automated fashion, if thats what you need.

share|improve this answer

Load up wireshark (http://www.wireshark.org) on the server, the XP machine, and the Windows 7 machine, and capture a network trace when copying the file. Compare the XP-->08 and Win7-->08 file copy operations and share anything interesting you see between the two.

That said... you mention that the 2008 Server is in a VM on your host (Windows 7) machine. Where is the XP machine that copies okay? It sounds like the copy operation may be going over a different network (host-->VM) than the XP-->VM copy operation (over your Intranet?)

share|improve this answer
    
Its useless to use wireshark. Why is he doing it? he cant change windows code. The solution is to modify windows configuration. –  acidzombie24 Jan 3 '11 at 18:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.