Slow file transfer between 2 computers

[videobruce]

If I transfer files from box A to box B using box A as the controlling terminal all is fine, BUT if I transfer the SAME files from the same location to the same location using box B as the controlling terminal the transfer is either very, very slow or dies altogether. I tried different files and the same thing. I reversed the transfer (B to A) and still the same thing. The computer which I used to initate the xfer shows no problem. If I do it from the other the xfer dies.

I have defragged both drives and changed NIC's in both boxes. I also forced 100 full duplex on both cards.
Both boxes are running 2k w/sp4 with new O/S installs.

Hope that made sense. Any ideas?

[videobruce]

I did more test xfers and reset the NIC's to 'auto' where I could and it seems ok now. Xfering a folder with many subfolders that contain many jpegs is a very slow xfer wher as a single large file flies.
Is this a 'Windows' thing?

[saphalline]

You've done everything you can on the PC end of things. I would now look into the cabling. Are you using a hub/switch, or just a cross-over cable? Have you tried replacing it?

[videobruce]

The router is a D-Link DI-604.
Regarding the slower xfer with a folder containing many subfolders?
There still seems to be a 'preference' of direction and which box sends the command to xfer the data. Can't quite narrow it down.

[malcore]

I have always found when using File and Printer Sharing that browsing the so-called network neighbourhood and/or copying files through explorer is a headache.

If I plan to copy large amounts of files over a home network, I usually do one of two things, or both. Map network drives (browsing and copying is much quicker) and/or use the xcopy command.

xcopy information: http://www.computerhope.com/xcopyhlp.htm#02

Another option may be to have a look at adjusting the IP MTU, TCP MSS and PMTUD on the systems. More info here:

http://www.cisco.com/warp/public/105/38.shtml

From article:


Problem Description and Possible Causes

Sometimes, over some IP paths, a TCP/IP node may send small amounts of data (typically less than 1500 bytes) with no difficulty, but transmission attempts with larger amounts of data hang, then time out. Often this is observed as a unidirectional problem: large data transfers succeed in one direction but fail in the other direction. This problem is likely caused by the TCP MSS value, PMTUD failure, different LAN media types, or defective links. These problems are described below: