Quick IT question - copying files

Page may contain affiliate links. Please see terms for details.
Transferring around 40,000 files (5Gb) between 2 w7 PCs on network. There appears to be a factor of 5 in time difference depending whether it's started from the source or destination. Is that normal? Source is a much older PC, quick to copy to rather than copy from.
 
U

User6179

Guest
Maybe anti virus scanning the files on one PC slowing it down ?
 
OP
OP
M

Markymark

Guest
Maybe anti virus scanning the files on one PC slowing it down ?
Maybe. I have same AVG on both. Both very similar, old one is source.
Old PC has all the files. Copy from that to new one took aorund 10 minutes. Ging to new one and copying files to it took over an hour
 
U

User6179

Guest
Maybe. I have same AVG on both. Both very similar, old one is source.
Old PC has all the files. Copy from that to new one took aorund 10 minutes. Ging to new one and copying files to it took over an hour

I have a similiar problem but its wifi related so I just download to a USB stick to transfer , an hour seems long even for an old PC.
 
Location
Salford
This is a feature of the networking hardware; when data are sent across a network they are split into "packets" that are re-assembled at the receiving end.

Network hardware can do the reassembly internally and not involve the processor on the receiving PC, "offloading" the work from the CPU (this is TCP Offloading). Some network hardware may be slower at doing this than others. I think this is what you have seen - one of your computers is better at reassembling these packets that the other.

It's not something I've done but I read around a bit and it is possible in Windows to turn off the TCP Offloading so that the CPU does the work but it looks complicated unless you're confident.

Maybe there is a networking expert on forum who can be cleverer than me but in the meantime, that's how I understand it.
 

machew

Veteran
In theory, they should be identical as they are using the same protocol (SMB) to send the data.
However, in reality, there are a lot of factors that can affect network transfers, especially when it comes to lots of files, or very large files (or both).

At the lowest level, the hard disk, reading is always faster than writing. when pulling the data, you are will be waiting less for the remote hard disk to send the data. The remote hard disk will be reading the data into cache and waiting for your machine to retrieve the data. However if one hard disk is slower and has a smaller cache this will change everything, the faster PC will be waiting for the next file, or part of the file to be read into the cache and sent
SMB can cause slowdowns as well. Slow SMB performance may occur if a delayed TCP/IP acknowledgement (also known as a TCP ACK) occurs in a "SMB: C NT transact - Notify Change" packet. By default, this behavior occurs as soon as SMB is using security signatures. If security signatures are configured, SMB must be processed synchronously by the redirector. The redirector has to wait until the current SMB command is fully processed before it continues with the next one. The redirector waits until it receives the TCP/IP acknowledgement from server.
So you would think pulling is better. However, this isnt always the case. In some instances, especially on unreliable networks, pushing can actually yield better performance.
To add to the confusion, other factors like total RAM, virus scanners, buffer sizes, backup programs, etc, will all have an effect on the transfer speed.
In the end, the only way to determine which is faster is to test it on your machines.
 
OP
OP
M

Markymark

Guest
In theory, they should be identical as they are using the same protocol (SMB) to send the data.
However, in reality, there are a lot of factors that can affect network transfers, especially when it comes to lots of files, or very large files (or both).

At the lowest level, the hard disk, reading is always faster than writing. when pulling the data, you are will be waiting less for the remote hard disk to send the data. The remote hard disk will be reading the data into cache and waiting for your machine to retrieve the data. However if one hard disk is slower and has a smaller cache this will change everything, the faster PC will be waiting for the next file, or part of the file to be read into the cache and sent
SMB can cause slowdowns as well. Slow SMB performance may occur if a delayed TCP/IP acknowledgement (also known as a TCP ACK) occurs in a "SMB: C NT transact - Notify Change" packet. By default, this behavior occurs as soon as SMB is using security signatures. If security signatures are configured, SMB must be processed synchronously by the redirector. The redirector has to wait until the current SMB command is fully processed before it continues with the next one. The redirector waits until it receives the TCP/IP acknowledgement from server.
So you would think pulling is better. However, this isnt always the case. In some instances, especially on unreliable networks, pushing can actually yield better performance.
To add to the confusion, other factors like total RAM, virus scanners, buffer sizes, backup programs, etc, will all have an effect on the transfer speed.
In the end, the only way to determine which is faster is to test it on your machines.
I was just curious. Was copying lots of data from old computer which is being replaced. I thought the best way was to action it form the new whizzo computer. However, this was massively slower.
 

machew

Veteran
I was just curious. Was copying lots of data from old computer which is being replaced. I thought the best way was to action it form the new whizzo computer. However, this was massively slower.
No problem, working in IT has meant that I always try and give a complete answer, this is due to years of management asking are your shore and how can you prove if
 
Not quite your question but I'd *really* recommend using a tool like Richcopy. You'll find it both faster and safer than just using file manager copying (or even CMD line).

You can find it here:- https://technet.microsoft.com/en-gb/magazine/2009.04.utilityspotlight.aspx
 
Top Bottom