Transferring same file between PC's one direction is faster than the other
-
- Member
- Posts: 29
- Joined: Wed Mar 01, 2017 7:00 pm
Transferring same file between PC's one direction is faster than the other
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???
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???
It depends on the network card.. It could just be "power" optimization on the laptop, or network card driver settings (TCP Offloads, etc.) slowing down transfers. It could also be simply NIC or CPU utilization - look at the task manager resource utilization during transfer, you will probably find it is quite high on the laptop.
-
- Member
- Posts: 29
- Joined: Wed Mar 01, 2017 7:00 pm
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
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
- YeOldeStonecat
- SG VIP
- Posts: 51171
- Joined: Mon Jan 15, 2001 12:00 pm
- Location: Somewhere along the shoreline in New England
It's not Apples to Apples...you have quite the variables here.
But first...copying from local to a destination..gives the appearance of faster, as drives usually read faster than they write. So you're pulling data from the local HDD to RAM and spitting it out in chunks. The more RAM, the larger the chunks. Your newer tower is faster, 64 bit, thus much more RAM available to the system. Although it's crippled with a Realtek NIC...it still runs faster than the old old XP rig running just 32 bit thus less RAM available for the system..and likely it's HDD, even though the same RPM, performs much slower. When copying from local to across the network..your source computer will "think" it's all done because it kicked it out the door and slams the door shut...but in reality the final writes may still be happening on the destination computer for a few milliseconds longer.
But first...copying from local to a destination..gives the appearance of faster, as drives usually read faster than they write. So you're pulling data from the local HDD to RAM and spitting it out in chunks. The more RAM, the larger the chunks. Your newer tower is faster, 64 bit, thus much more RAM available to the system. Although it's crippled with a Realtek NIC...it still runs faster than the old old XP rig running just 32 bit thus less RAM available for the system..and likely it's HDD, even though the same RPM, performs much slower. When copying from local to across the network..your source computer will "think" it's all done because it kicked it out the door and slams the door shut...but in reality the final writes may still be happening on the destination computer for a few milliseconds longer.
MORNING WOOD Lumber Company
Guinness for Strength!!!
Guinness for Strength!!!
-
- Member
- Posts: 29
- Joined: Wed Mar 01, 2017 7:00 pm
What I meant by the "apples to apples" was same file, same path, same hardware at each end.
I did forget to mention I use BitMeter as a data speed monitor tool (on both boxes), not that lame M$ file transfer window 'bad guess'.
Interesting about the "kicking it out the door" analogy. I didn't look at the other graph to see if it shows the data still arriving or not. Both boxes are in the same room, but not next to one another.
I did stumble across this thread;
showthread.php?283927-Implement-windows ... -windows-7
Is that related here?
I did forget to mention I use BitMeter as a data speed monitor tool (on both boxes), not that lame M$ file transfer window 'bad guess'.
Interesting about the "kicking it out the door" analogy. I didn't look at the other graph to see if it shows the data still arriving or not. Both boxes are in the same room, but not next to one another.
I did stumble across this thread;
showthread.php?283927-Implement-windows ... -windows-7
Is that related here?
Sending and receiving uses different buffers and loads the NIC chipset and the CPU differently. I would look at the following:
1) CPU utilization at the laptop when sending/receiving (this only shows you half the picture, as you don't see how taxing the transfer is on the NIC)
2) NIC settings at the laptop. Turn off all TCP offloads, etc. in the network adapter properties. Keep in mind some of those NICs may not be able to sustain full gigabit transfer speeds in both directions, especially if the chip has to do additional work like calculate checksums, buffers getting filled, transfer queues, etc.
3) Look through these article for possible tweaks:
https://www.speedguide.net/articles/lan ... -8-10-5819
https://www.speedguide.net/articles/net ... ation-3449
1) CPU utilization at the laptop when sending/receiving (this only shows you half the picture, as you don't see how taxing the transfer is on the NIC)
2) NIC settings at the laptop. Turn off all TCP offloads, etc. in the network adapter properties. Keep in mind some of those NICs may not be able to sustain full gigabit transfer speeds in both directions, especially if the chip has to do additional work like calculate checksums, buffers getting filled, transfer queues, etc.
3) Look through these article for possible tweaks:
https://www.speedguide.net/articles/lan ... -8-10-5819
https://www.speedguide.net/articles/net ... ation-3449
-
- Member
- Posts: 29
- Joined: Wed Mar 01, 2017 7:00 pm
-
- Member
- Posts: 29
- Joined: Wed Mar 01, 2017 7:00 pm
If your resource utilization on your Windows machines is low while making transfers (look at Task manager), you may also be reaching the limit on your switch. The only other idea I have is it could be experiencing some type of EMI interference as well (move it away from possible sources of radio interference, including CFL light bulbs, power supplies, UPSes, monitors, etc.)
-
- Member
- Posts: 29
- Joined: Wed Mar 01, 2017 7:00 pm