TR Forums

When I transfer file from A machine to B machine via Ethernet, I can do it using A or B. Is the transfer speed supposed to vary depending on which way it is done? How does the resource utilization differ between the two methods?

An incident that prompted me to ask the above is as follows: The machine A is Pentium 4M(2.4GHz) and the machine B is Phenom II x4(3.5GHz), and the network is Fast Ethernet(10/100). The transfer speed using the machine A is 15 min for 10GB file, and it is one(1) hour to do the same from the machine B. I thought the latter would be faster contrary to what happened.

I can't really help you as I'm a paranoid freak and keep every computer in the house separate from each other:)

My only guess is that the nic on one of the motherboards is not the same speed as the other, just a guess.

Between two machines with all other variables being equal the transfer speed shouldn't be different, so transferring one file from A --> B should take the same amount of time as transferring the same file B --> A.

HOWEVER, as above, there are a large number of device or network settings that could change the effective throughput of the transfer, meaning that one faster than the other.
Here is an incomplete list of things that could cause your issues, and I'm sure other gerbils know of other issues too:

1. Frame fragmentation when the MTU is too big: Every ethernet network has a maximum transfer unit (MTU) for each ethernet frame that goes over the wire. A common MTU in 10/100 networks is 1500 bytes, but smaller sizes may be needed in some circumstances (for example, VLANs add additional header bytes and may require smaller MTU sizes to compensate). If you try to send frames that are too big, then fragmentation occurs and that can slow things down considerably. If machine A has a smaller MTU that is *not* fragmenting, it could send data to machine B faster, while machine B would experience fragementation and be noticeably slower at sending data to machine A.

2. Network traffic: If there is other network traffic occuring during the file transfer then the transfer can slow down during heavy network utiliziation. You may have just been doing the first transfer when the rest of the network is quiet, and the second transfer when the network is busy. Having a switch (instead of hubs which are a lot less common these days) helps, but if either computer A or computer B has high network activity outside of the file transfer, then you'll experience slow downs.

3. Network driver wonkiness: Check your drivers for both network cards in machines A & B to make sure everything is setup properly. Both machines should show 100 MBit full-duplex for their corresponding NICs.

4. Wonky switch or cabling: This is less likely, but some switches just don't get along with other pieces of hardware and/or you might have a flaky cable. I'm saying this is less likely because you would likely see issues going in both directions with data transfer, but, for example, if the receive wires are OK in a cable but the transmit wires have a noisy connection, then one machine could conceivable receive data at high speed, but only be able to effectively transmit at lower speeds. Another issue with the switch could be that you are somehow encountering high packet loss when data goes in one direction, but not in the other direction.

churin wrote:

The transfer speed using the machine A is 15 min for 10GB file, and it is one(1) hour to do the same from the machine B.

I had that problem with a gigabit connection before, turned out the cable was crappy.

I'd look at the cable.

There could also be something unrelated to networking causing it. A hard drive on its way out could have a real adverse affect on transfer speeds, whether local or across a wire.

Most importantly, can you recreate these results?

churin wrote:

The transfer speed using the machine A is 15 min for 10GB file, and it is one(1) hour to do the same from the machine B. I thought the latter would be faster contrary to what happened.

The speeds you're getting are abnormal and are way below what the CPU could provide. Try running a network tester. Exchange cables or NICs. With a remotely recent machine you should saturate Fast Ethernet without much trouble (avg. hard drive=8x Fast Ethernet...). You processor can easily saturate Gigabit Ethernet if storage is fast enough...

EDIT:
Double checked your details and calculated the following:

PC A: [email protected]
PC B: [email protected]

xfer 1 x 10GB file from A to B

Using A = 15min

Mb/s= 10GB/15min x min/60sec x 8Gb/GB x 1000Mb/Gb = 88.8Mb/s

10*8*1000
------------ = 88.88Mb/s
15*60

Using B = 60min

10*8*1000
------------- = 22.2Mb/s
60*60

I'll leave the original text below unchanged, as it still applies in general.

Your results show the opposite of what one should expect. While file xfers don't use alot of CPU time, using the Phenom II X4 should have been much faster than using PC A ([email protected]).

So what you're doing is using PC B([email protected]) to go through the network, read data from PC A hard drive, then bring it back through the network, and WRITE it on it's own HD.

The problem seems to be originating on PC - B.

I'm wondering if the NIC on PC-B is set for half-duplex, or if the offload options on the NIC are disabled. Some NIC's allow some of the work to be offloaded FROM the CPU to the NIC to enhance network performance. This way, the NIC does more work on it's own WITHOUT "interrupting" the CPU. It may be that the offload settings on PC B NIC are disabled instead of being enabled. I'd also ensure full-duplex and flow control is enabled on PC B (as well as A for that matter).

If all these things are already set, then i'd swap network cables and try the exact same test again. If the results are opposite, you have a cabling problem, again assuming both NIC's are set to full-duplex, auto-negotion and flow-control enabled.

The information below I'll leave as-is, even though it doesn't specifically resolve THIS particular issue, just gigabit network performance in general. Apologies!

It seems the write speed of the drive on machine A is much slower than B. (EDIT: <--- does not apply since this was a one-way only test, not two-way)

Write and Read speeds of your drives are probably going to be the limiting factor in network file xfer performance.

I'm betting machine A ([email protected]) has a much slower drive with much slower write speeds than the drive you used on machine B (AMD @ 3.5Ghz).

Reads are generally much faster than writes, so that if you're writing to a slow drive, it will take longer to xfer a file to it, than it would to copy a file FROM the drive since you'll be reading from it.

Both PC's would probably benefit from being on a gigabit network which has:
1 - Gigabit NIC's (enable JUMBO frames, which should NOT affect internet throughput, but just increase your LAN throughput)
2 - Gigabit Switch, preferably a 'nice' one from HP (have this one myself), or even Netgear (http://www.newegg.com/Product/ProductLi ... ch&x=0&y=0).
3 - Cat5e or Cat6 network cabling throughout

Be aware though, that if you're xferring lots of small files, even on a gigabit lan, the throughput will be noticeably less than if you're transferring large files.

I usually get between 250Mb/s to over 800Mb/s file xfers both ways between laptop and PC which have native Gigabit NIC's.

Of course, there is a 4th option for even better performance...

Put the data you need to xfer on SSD's on BOTH PC's. The performance I noted above, is with data NOT on SSD's though I have them as boot devices on both devices mentioned.

churin wrote:

When I transfer file from A machine to B machine via Ethernet, I can do it using A or B. Is the transfer speed supposed to vary depending on which way it is done? How does the resource utilization differ between the two methods?

An incident that prompted me to ask the above is as follows: The machine A is Pentium 4M(2.4GHz) and the machine B is Phenom II x4(3.5GHz), and the network is Fast Ethernet(10/100). The transfer speed using the machine A is 15 min for 10GB file, and it is one(1) hour to do the same from the machine B. I thought the latter would be faster contrary to what happened.

Ever since Windows 95 there has been a weird "push / pull" mechanic in file shares.
If you 'pull' the file to you, from another PC it generally seems to be quicker - this isn't always the case but often is.
I've never ever seen high transfer speeds dragging (sending) to another machine, whereas I've many times seen faster speeds pulling to a machine.

I am not factoring disk speed in to my post, however I know for a fact disk speed hasn't been the cause of the problem in the past.

Are A and B connected via crossover cable or are they both part of a larger network?

I should have used the words "Push/pull" as used in AbRASiON's reply to avoid misunderstanding as noticed in other responders' replies. Please note that the file is copied only from A to B by either method.

Correction to a part of my original post being "the network is Fast Ethernet(10/100)": The hardware used are a Gigabit router, Cat6 cables, 10/100 Nic on A and Gigabit Nic on B. This should also answers quey by slinky.

There are comments on cable being possibly faulty. But if it is, doesn't it affect the operation the same way whether I am pulling or pushing the file?

This may or may not help, but have you tried teracopy? It is supposed to speed transfers over the network, but not sure if it would help since one end is only 100 Mbit, and I realize it doesn't answer your original question.

It might be that the "sending" computer prioritizes the send since it's user-initiated on that computer, but in the case of pulling the file, the host computer doesn't prioritize it since it's a network request (in order to keep the computer responsive for the user at its keyboard). Dunno though.

Which OS are you running, and do you have other programs running while you try the file transfer. If you have Vista, there is a problem with the multimedia class scheduler if you have any media software running at the same time, and that will include software like winamp or steam. Such would limit one of the directions of push/pull to much less then what it should be. Dont remember which direction right now, but it think its from other source to local computer that is limited. So copying from a computer to somewhere else wouldnt be impacted.

I would focus on drivers/software; A hardware issue iswould affect all file transfers regardless of which machine initiated them.

If you can't see anything obvious, I would start by deleting the adapter and then reinstalling with latest drivers. This will give you the benefit of up-to-date drivers and a whole new configuration of adapter and protocol settings. I have seen connections go flaky because third-party software messes around with connection settings like QoS, Topology and ARP settings. Unless you're really confident all of these things are as they should be, deleting a connection and recreating it is the fastest way to get the default options back.

Another thing to check is of course third-party firewall / network utilities / encryption software. If you use any of these then disable them to test.

streagle27 wrote:

EDIT:
Double checked your details and calculated the following:

PC A: [email protected]
PC B: [email protected]

xfer 1 x 10GB file from A to B

Using A = 15min

Mb/s= 10GB/15min x min/60sec x 8Gb/GB x 1000Mb/Gb = 88.8Mb/s

10*8*1000
------------ = 88.88Mb/s
15*60

Using B = 60min

10*8*1000
------------- = 22.2Mb/s
60*60

Huh?


(10 GB) / (15 minutes) = 11.3777778 MB / s

(10 GB) / (60 minutes) = 2.84444444 MB / s


Looks like you got lost on the train tracks of death.


Anyway - I'd point at messed up settings or software before anything else. A bad cable should affect both transfers since they're going in the same direction, only the method is changing (pushing versus pulling).

Are both machines running the same OS?


EDIT: It could be something due to frame sizes between your gigabit network and the 10/100 network. Pushing from A would use the frame sizes for 100 Mbps and work just fine...pulling from B would use requests and packets potentially larger than can be efficiently handled by the 100 Mbps network. This would only be an issue if there was a configuration issue though...or you have a really, really crappy switch. I think, anyway.

If you have an on-the-fly virus scanner enabled on one of the machines that could make a huge difference, depending on how it is configured.

I really hate to report this after all that said and no change is done with the machines but now I am seeing the same speed of 15min either for pushing or pulling the file. There are three separate installs of W7s on B. I tried all of them but the speed is the same 15 min.

What happened just before my original post: I tried pulling the file from A to B and saw "1 hour remaining" and I waited several minutes but the message stayed the same and the bar graph progress looked very slow. So, I cancelled the transfer. Then I tried pushing the file from A to B, "15 minutes remaining" was noted and the transfer completed in 15 minutes.

Somewhere associating with file transfer operation must be in abnormal condition when I saw "1 hour remaing". I should have double checked before seeking help.

So you never actually *timed* it taking 1 hour?

Windows' estimate of time remaining is nearly worthless; it gets especially bad if you are copying lots of files of widely varying sizes. I've seen it give estimates of multiple days for a copy that only takes an hour or so; I've also seen it stick at "10 seconds remaining" for several minutes.

Things get even worse if you have on-access virus scanning enabled, or are talking to a shared server that other people are also using.

http://xkcd.com/612/
http://agileom.com/index.php/windows/fo ... -the-file/

Much ado about nothing.

Streagle was measuring in megabits and you were measuring in megabytes. What he did kind of made sense since we're looking at the transfer rate in comparison to the theoretical maximum of 100 Mbps. But as you said, it's moot now.

Jason181 wrote:

Streagle was measuring in megabits and you were measuring in megabytes. What he did kind of made sense since we're looking at the transfer rate in comparison to the theoretical maximum of 100 Mbps. But as you said, it's moot now.

Bah. I need more coffee before I browse TR. I'm not sure how I read that and saw "MB" instead of "Mb".

just brew it! wrote:

So you never actually *timed* it taking 1 hour?

Yeah, and like the man said, Windows time estimates are usually pretty worthless (anyone who's ever used explorer to copy a file should know that!).

Always, always try to reproduce the issue before reaching out for help. If you can't make it happen twice (or once in this case), it may not be a real problem.

absurdity wrote:

just brew it! wrote:

So you never actually *timed* it taking 1 hour?

Yeah, and like the man said, Windows time estimates are usually pretty worthless (anyone who's ever used explorer to copy a file should know that!).

The time estimates are not necessarily worthless. If you wait a while you can estimate how long it will take to complete pretty accurately. It is true that the displayed estimate some times fluctuates by going up and down instead of going down steadily. But if you wait a while the elapsed time and the percentage of the bar graph progress give you pretty accurate estimate.

Always, always try to reproduce the issue before reaching out for help. If you can't make it happen twice, it may not be a real problem.

Yes, this is the mistake I made as I admitted in my previous post.

absurdity wrote:

Yeah, and like the man said, Windows time estimates are usually pretty worthless (anyone who's ever used explorer to copy a file should know that!).

I think estimated times are much more accurate in Windows 8. In fact, I think the file transfer window is the best change I've noticed between Windows 8 and Windows 7.

If possible i would get a gigabit PCI/PCI-e card for the 10/100 machine.

kumori wrote:

absurdity wrote:

Yeah, and like the man said, Windows time estimates are usually pretty worthless (anyone who's ever used explorer to copy a file should know that!).

I think estimated times are much more accurate in Windows 8. In fact, I think the file transfer window is the best change I've noticed between Windows 8 and Windows 7.

That's actually pretty sad.