After my post about slow file copies with Windows Vista SP1, some of you offered potential fixes and asked for an update once the problem was resolved. I have been taking a crack at this problem every so often without going into all-out, throw-down problem-solving mode since the prospect of spending hours ripping up my main PC for a fix that may or may not be possible with current OS and driver revisions doesn’t seem especially inviting.
Anyhow, I made another run at the problem again today. Here’s a brief recap for you.
The problem is intermittently (very) slow network access, disconnect messages, and intermittent failed copies of large files from a Vista x64 SP1 machine with a Realtek RTL8168B/8111B GigE PCIe NIC to a Windows XP SP2 x86 machine. The problems occur not just in Windows Explorer, but also when I’m saving files with another program, like Firefox downloads or the like. The target machine serves files to any other system on my network (both XP and pre-SP1 Vista systems) quickly and with zero problems.
These problems started with the installation of Vista SP1. So far, I’ve tried the following measures, with no improvement:
-Updating to RealTek’s latest NIC and audio drivers available today
-Enabling jumbo frames with (4K max) manually on both machines
-Manually configuring both NICs for full-duplex gigabit operation
-Setting “netsh interface tcp set global autotuninglevel=highlyrestricted”
-Setting “netsh interface tcp set global autotuninglevel=disabled”
-Accessing the remote system via a mapped drive or a UNC share (happens both ways)
-Disabling my (Avast) antivirus’s real-time file scanning and network AV protection modules during a file copy
None of these changes have even moved the needle. The problems are bad enough that everyday use of this machine in our networked environment is a trial. I suppose the next steps may involve hardware changes, such as a discrete NIC. I’d really prefer not to make such a change for an obvious software problem (this all worked fine before the installation of Vista SP1), but there may not be another option here. I’ve tried pretty much everything suggested in this MS knowledgebase article, with the exception of using robocopy, since resorting to a CLI-based file copy utility isn’t a fix; it’s a kludgy workaround (and its presence in the KB article suggests this problem must be somewhat intractable).
Sooooo… no good news to report, although I supposed I’ve learned a lot about what doesn’t help. Whee.