Speeding Up File Transfers in Windows 7
File transfers in Windows involve many factors, any one of which can present problems. In a typical Windows network with a mix of clients and servers, file transfer performance can vary wildly. Because it's such a common operation, this white paper examines some of the reasons for the variations and unearths a few tricks and tips that might make file copying snappier on your network.
File transfer speed is a big deal. In fact, user response to Vista (pre-SP1) was negative in large part because Vista transferred files in many situations more slowly than XP, its predecessor.
The complex thing about file transfers in Windows is that they involve many factors, any one of which can present problems: which mix of operating systems you're using; Network Interface Card (NIC) settings; layered software (such as antivirus); switch settings; whether you're transferring one large file or lots of small ones; etc.
One thing is for sure: in a typical Windows network with a mix of clients and servers, file transfer performance can vary wildly. Because it's such a common operation, it's worth looking at some of the reasons and, in the process, unearthing a few tricks and tips that might make file copying snappier on your network. That's what this white paper does, and it is organized as follows.
Pull vs. Push
File System Buffering
Drive Compression and Encryption
Local Disk Copies
One of the reasons that file transfers are faster with newer versions of Windows has to do with the version of SMB (Server Message Block) that these operating systems support. The SMB file-sharing protocol (which you may also know as CIFS, the Common Internet File System) has been around since Windows for Workgroups, but it's been stuck at version 1.0 for many years.
File transfers between Vista and Windows 2008 use SMB 2.0. Transfers between Windows 7 and Server 2008 R2 use SMB 2.1. (Any transfers involving XP or Server 2003 on either end use SMB 1.0, basically the same versionthat's been around for years.) The version of SMB that is used in any given file transfer is the result of a negotiation between the two computer operating systems involved.
SMB 2.x decreases overhead by allowing multiple requests to be collected into a single packet. It also supports much larger buffers (with the server controlling the size of the Maximum Transmission Unit (MTU), and permits more simultaneously open file handles. SMB 2.1 goes further by supporting "pipelined I/Os" in which a request can be sent before the previous request has been answered.
So how much of an improvement is 2.1 over 2.0? With a 2-gigabyte file size and a 10-gigabit Ethernet network, Microsoft estimates a 30% to 40% gain over SMB 2.0 (which, itself, is a big improvement over SMB 1.0). The large MTUs also let SMB 2.1 systems cache larger directories, which will make copies of folders having more than about 500 entries go even faster.
Finally, here's a nice benefit: Access to DFS (Distributed File System) shares is also accomplished via SMB 2.x messages now, so you should see improvements when copying to and from DFS shares as well as "normal" shares.
Pull vs. Push
I don't necessarily understand the underlying reasons for this particular effect, but it seems to be generally true that "push" transfers - that is, those in which the copying user is working on the system containing the file to be copied to another system - can be dramatically faster than "pull" transfers, those in which the copying user is working on the system to which the file is destined. The difference can be on the order of 50% faster in the "push" scenario!
One thing to check is the link negotiation settings on all Network Interface Cards, (NICs) (see Figure 1) and switches. Some network administrators report best performance with consistent settings. I've heard frequently that "auto detect" may not work as well as an explicit setting ("1000 Mbps"). Another NIC setting to test is flow control. If the NIC supports jumbo frames, and your switches do, too, you may be able to improve file copy performance by enabling this feature. You can experiment with receive buffers also. All these settings are highly dependent on specific NICs and drivers, and on interactions between NICs and switches, so you have to do some experimenting to see what has the greatest impact.
The NETSH command lets you make a number of Registry settings that can have a sometimes-huge impact on file transfer performance in Windows. Here are some to consider: