Transferring same file between PC's one direction is faster than the other

[videobruce]

I hope this is the right place to ask this. here is the situation;

Two PC' s
one a newer tower running Win 7, the other a older laptop running XP Pro
Wired connection thru a router and a 'switch' with no special priorities or restrictions to bandwidth. Both static IP's (if that matters)

The file is a mp4 around 100MB that I chose specifically to test 50' CAT5e jumper cables before I 'fish' them. I used the "move" function from and to the same partitions on both PC's. All apples to apples.

Using the laptop as the control; from that to the tower speed is fairly steady at 75 Mbps
returning the file, speed is between around 20 to 55 Mbs

Now, the same test, but from the tower; transferring the file from the tower to the Laptop speed varies from 66 to 95 Mbps,
returning the file from the Laptop back to the tower speed is 95 Mbps with a couple drops to 65 Mbps.

Ok, why is the speed far faster using the tower as the control station than the laptop transferring the exact same file, the exact same way???

[Biscuit]

Different NICs probably. Some work better than others.

[MaddAussie]

It will probably have a slower HDD that will be writing the file to in laptop, the windows file transfer speed widget shows the end to end process, i.e. read > transmit > write.

[videobruce]

I used BitMeter to monitor speeds, not the 'lame' M$ 'bad guess' transfer window.

Both cards are gigabyte. Win7 is 64 bit, XP Pro sp3 is 32 bit (I forget to add)
But, all of the above doesn't explain why initiating from one machine or the other affects transfer/speed/time. The process is the same. After I click "move", why/where would it make a difference?

To possibly sum this us clearer;
File X transfer from A to B using A as the controler
File X transfer back from B to A using A as the controller

then;
File X transfer from A to B using B as the controller,
File X transfer back from B to A using B as the controller

The ONLY differences are the direction and which PC initiated the command.


Both PC's are AMD based,
Tower has a AMDFX-8350 & a AMD 970A chipset MB. The NIC is a Realtek PCIe GBE. The specific HDD that has the file is a Hitachi 7200rpm HUA723020
Laptop has a AMD Turion II M600 (the specs doesn't show the MB chipset) The NIC is a Marvell 88E8072. The (only) HDD is a 7200rpm WD WD5000BPKX

[DanceswithUnix]

The file transfer process is not symmetrical: One PC is running explorer as a client program and the other is running its file serving service to act as a file server. So, Writing from client on A to server on B is not quite the same as reading on a client on B from a server on A even though the data is going in the same direction.

Having said that, 100MB is nothing and should fit in RAM on both machines. If you are talking 95 megabit per second as you have written then I presume your router only has 100Mbit ports on it? I would have to wonder what is going wrong to give a reading as low as 65Mbit/s, though possibly the small file you are transferring is giving iffy readings and the network stack doesn't get much past the slow ramp up. Really, I would expect to saturate a 100Mbit network with modern 64 bit hardware.

Try again using a DVD ISO image or something similar of at least 1GB in size.

[videobruce]

There is there one thing I missed, the Switch is only 100Mb, but that only accounts for the top speed, it shouldn't account for the wild variances.

[DanceswithUnix]

There is there one thing I missed, the Switch is only 100Mb, but that only accounts for the top speed, it shouldn't account for the wild variances.

As I said, something is wrong. I suspect packets are getting dropped, and that could be anywhere and for all sorts of reasons and only some time pouring over a Wireshark trace of the slow transfers is going to tell you what it is.

[Dareos]

too many variables tbh.

You'd need to start with 2 identical machines and change 1 component at a time while testing transfers to get a true reflection of whats happening.


It may simply come down to the different way 7 and xp handle transfers

[videobruce]

"tbh"??

I understand the troubleshooting process; divide and conquer.

[Splash]

"tbh"??

To Be Honest. I think Dareos is likely the closest (though DancesWithUnix is very correct in saying that the only way you're going to be 100% certain is with some Wireshark captures - have a look at https://osqa-ask.wireshark.org/quest...nsfer-slowness.) - Windows XP and Windows 7 have different network stacks, different drivers and probably most importantly different versions of the SMB protocol.

[DanceswithUnix]

Windows XP and Windows 7 have different network stacks, different drivers and probably most importantly different versions of the SMB protocol.

... and network clients, server processes and socket tuning. If the machines were on a 10Gbit network link that would all be very interesting, but when bottlenecked as badly as 100Mbit none of that should matter.

Divide and conquer isn't going to help here, hence my suggestion that you monitor the packets on the wire. Wireshark will show retransmissions so you can see if/where packets are dropped.

[videobruce]

I'll look into that Wireshark, but it looks as it's way over my head.

[EndlessWaves]

It's quite a small test file so the transfer is only taking 10-15 seconds. I'm not familiar with BitMeter but that's within the range that startup times for the transfer could affect averaging of speeds

It might be worth trying with a gigabyte file that takes a couple of minutes, ~1.4GB would be a good size as that's two minutes at 95Mbps.

[videobruce]

Bit Meter is here;
https://codebox.net/pages/bitmeter2
DU Meter is here;
https://www.hageltech.com/dumeter/about

I have used one or the other for well over the past 10 years, I even have it load at startup. Something I never do with programs with only a few exceptions.

When I get to it I will try using a larger file. All I was concerned about at the time was if the cable was good or not. Something file size was material. But, looking at the graph as even a small file was being transfered clearly told the story.