Hi all, Have an interesting problem, I have 2 identical servers, both of them running MS Windows Server 2003 R2 Enterprise x64 SP2 with all the latest patches / updates. Using FastCopy (basic windows file copy) to copy large files (>1GB) between them, going from server A -> server B : transfer rate ~ 10MB/s BUT, going from server B -> server A : transfer rate ~ 3-4MB/s As a 'control' I've also tested transfer rate from and to each server A and server B to another server C and there are no issues (fast transfer rate ~10MB/s). server A <-> server C; server B <-> server C : no issues! Now assuming the network environment is functioning 100% (ie. no dropped/duplicate packets, no protocols in between, etc) what are some possible causes on the systems for this unusual behavior? Why the huge difference in transfer rate between the 2 directions? I've played around with TCPWindowSize and saw maybe a very slight improvement ~1-2MB/s. Are there any other tweaks that may be done? Thanks! -Dave

Also has anyone encountered or have any input on slow start?

Using the same NIC and version of NIC Drivers? Any issues on the network port? Did you monitor the network port utilization? Santhosh Sivarajan | MCTS, MCSE (W2K3/W2K/NT4), MCSA (W2K3/W2K/MSG), CCNA, Network+ Houston, TX http://blogs.sivarajan.com/ http://publications.sivarajan.com/ This posting is provided "AS IS" with no warranties, and confers no rights.

hi , Fastcopy is not a microsoft application and even if you open a support incident with MS they would say you are using 3rd party app which they cannot troubleshoot. Please understand that file sharing involves different drivers at the kernel level along with the MUP . which means that when you access the files share using \\namepipe\pipe then you are invoking Mup.sys which establishes interprocess communication. So i would like you to test with conventional microsoft way using a) \\ipaddress ( through run / shell ) b) \\netbios ( with uses MUP ) c) \\fqdn TCP window size would not really help because you are having an abstraction layer which is fastcopy . You have to make sure the follwoing files are upto date a) mrxsmb.sys b) rdbsss.sys c) Nbt.sys d) mup.sys other option is to check the behavior in safe mde with networking ( using explorer to access shares and observe the speed ) Toggle your n/w card for 100 mbps full duplex

So a little more background on the 2 servers, both NIC cards are set for AUTO / AUTO. Network port utilization is within normal range, no spikes or anything. System resources are running fine, no spikes. One server was actually moved from a different geographical location to where it is now. Before it was moved, everything transferred flawlessly, high transfer rates, no issues. Now in its current location, its on a different network, but all computer settings remain the same. Does anyone think it is still a server issue or possibly a network issue? My network guys are coming back to me saying that the network is fine. Please advise. Thanks!

To really narrow it down and determine if its a Server or Network issue, you need to isolate everything. Remove Network and Switches from the picture, by using a cross-over cable between to the two servers, OR plug them into an isolated switch and run your test again. If the same thing happens, then its a server, NIC, Cable issue. Replace the NIC and cable parts in turn and retest. If the problem remains, then its most likely the Server OS, or the hardware/config. Once you determine what it is or isn't then you can focus on that. Another good test to run would be a packet capture during the file copy. Then run the TCP retransmit analysis using the Network Monitor Expert. Other things to check would be the NIC settings themselves. Really good NICs offer Transmit (TX) and Recevice (RX) buffers that can be configured. Verify these are set the same on both servers, along with other settings. Also, it this a 1GB NIC connected to 1GB Network? If not what are the MAX NIC and network speeds? Final thought/comment. Forget about magical throughput numbers output by a program. A proper test is based on TIME it takes to complete, not the estimated throughput displayed. For example: if the copy in one direction takes 3 minutes to complete, but the reverse takes 3min 5 secs, that's not an issue and your throughput numbers don't matter. However, if its 3mins in one direction and 4mins in the other, then its an issue. Make sure bother HD's are defragged as well.

Hi, I experienced a similar issue when trying to copy files between Windows 7 system, one direction is fast, one direction is slow. It turns out to be a switch problem, changing a port solved the problem. To verify, as Gunner suggested, try to capture the network traffic during transferring files. I my case, I see a lot of re- transmission. You can download Microsoft Network Monitor. http://www.microsoft.com/downloads/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en 1. Run Network Monitor and start capturing on the source system. 2. Reproduce the problem. upload the file to Windows Live SkyDrive (http://www.skydrive.live.com/). If you would like other community member to analyze the report, you can paste the link here, if not, you can send the link to tfwst@microsoft.com. Thanks.This posting is provided "AS IS" with no warranties, and confers no rights.

Any udpate?Santhosh Sivarajan | MCTS, MCSE (W2K3/W2K/NT4), MCSA (W2K3/W2K/MSG), CCNA, Network+ Houston, TX http://blogs.sivarajan.com/ http://publications.sivarajan.com/ This posting is provided "AS IS" with no warranties, and confers no rights.

One server was actually moved from a different geographical location to where it is now. Before it was moved, everything transferred flawlessly, high transfer rates, no issues. Now in its current location, its on a different network, but all computer settings remain the same. Gunner999, he failed to mention in the first post the (potential) key phrase "Different geographical location". TR Engineer, I'm guessing this is still the case, since you mentioned "On a different network" and then mentioned "My network guys" I presume that this wold be a different geographical area still? Usually a packet travelling from Site A to Site B will take a different route in the network world than the other way around. A traceroute would help nail that down. A program I use to use called VisualRoute would map out the latencies between each hop, which could be the issue, then again, maybe not. Anyhow, let us know... James