5

I am copying a small number of large files between a Vista x64 SP1 workstation and a Windows 7 RC workstation. Windows says it will take 7 hours to copy 117GB of data from one computer to another over an uncongested 1 GBit/s switch. Robocopy isn't doing much better.

I seem to remember from my Exchange days, that there were several utilities that claimed to copy very large files between servers. Are these utilities still available and if so, which are most effective in the above situation?

Edit:

I am trying a Robocopy to a USB 2.0 external HDD, as this is all I have available at the moment and it is faster, this is unusual, as the two computers I am using are the only two computers connected to this particular 1GBit/s switch.

Edit 2:

Seems to be some problem with the NIC on the source, can't get the throughput above 3MB/sec after swapping everything else out. As this is the old machine I switched to using the external HDD which copied faster than the NIC, however it still took 3 and a half hours in total.

p.campbell
  • 4,407
  • 6
  • 41
  • 51
Richard Slater
  • 3,228
  • 2
  • 30
  • 42

13 Answers13

10
117GB/7H = 4.6MB/s

Something is wrong here.

Check for disk fragmentation, network misusage, another program grinding the drive or faulty hardware; Windows w/1Gb network can saturate the bandwidth that 7200 SATA drive can provide, i.e. 60-70 MB/s

I might also suggest that you create yourself a nice scheduled task to transfer the file(s) overnight.

Dani
  • 1,226
  • 1
  • 13
  • 20
  • Disk fragmentation is below 3%, target machine is a new build. Both PCs connected to 1Gb unmanaged switch with a third uplink to a 1Gb switch, I presume the switch should just route from one port to the other. No errors reported in the event log to suggest hardware problem, any other diagnostic thoughts? – Richard Slater May 11 '09 at 12:45
  • 1
    look at the network utilization, does it look capped? it should roam above 50%. run a disk diagnostic with hdtach or similar utility. Also look at the cables - dodgy cat5 cabling can mess up the transfer rate; if you can, try quality shielded cat6 cable. – Dani May 11 '09 at 12:54
  • 1
    Seems to be some problem with the NIC on the source, can't get the throughput above 3MB/sec after swapping everything else out. Dosn't matter as this is the old machine. – Richard Slater May 11 '09 at 14:46
  • Good catch on the throughput red flag! +1 – squillman May 11 '09 at 15:22
  • how did you check the throughput? – Svish Jun 08 '09 at 07:46
3

For something that large and considering it's a local copy I would either plug the hard drive of one of those PCs into the other and do a direct copy. Alternatively I would use an eSATA hard drive to do the transfer. That's going to be way faster than even GigE.

That all assumes this is a once off, which is how I read your post.

cletus
  • 9,999
  • 9
  • 37
  • 40
  • I'm not sure that eSATA would be faster than 1G; you can read and write simultaneously and as I said (and witnessed), 1G provide enough headroom in terms of bandwidth for a 7200RPM drives – Dani May 11 '09 at 09:52
  • @cletus: 'way faster'? 7200RPM 3,5" HDD have write speeds of 70-90MB/s. 1GBit/s is 125MB/s, even if you take in account protocol overhead, it's more then enough. – vartec May 11 '09 at 10:57
  • Hard drives top out over 100MB/s http://www.extremetech.com/article2/0,2845,2173845,00.asp and you won't get that out of GigE. – cletus May 11 '09 at 12:12
  • yes, but you're missing on the concurrent read/write of the network vs. eSATA which halves the effective throughput – Dani May 11 '09 at 12:20
  • @cletus: that's *read* speed. writes are a lot slower. – vartec May 11 '09 at 14:25
1

Well, it should take about half an hour to copy that.

Anyway, how long did you wait before canceling it? Did you take a look at the details, to check actual copy speed? Vista's initial estimates are very often way off. After a while it recalculates the speed to give you better estimate.

vartec
  • 6,217
  • 2
  • 33
  • 49
1

Here's a tip that says that disabling the network stack's receive-window-auto-tuning may fix your problem. Run As Administrator:

netsh int tcp set global autotuninglevel=disabled

You may also want to consider enabling jumbo frames (9000 bytes MTU) on each system to see if that helps.

aharden
  • 1,460
  • 10
  • 11
1

I have heard of this happening with a lot of people using vista to copy over the network.

I did a quick google search to verify. There a lot of "fixes" listed here.

This article explains the Vista SP1 file copy improvements and why it works the way it does.

user2287
  • 227
  • 1
  • 2
1

I've seen slow copy performace over ipv6, especially over wireless, as a test did you try disabling ipv6 just as test?

you could be running into the vista performance problems, smb2 probs, differential network copy etc, I think there are bugs somewhere in those also

also try teracopy, it optimizes the transfer

Scott Kramer
  • 255
  • 3
  • 6
  • 15
0

Try testing the raw TCP performance with a point to point TCP benchmark. Everest has one for example. Or write a 10 line script.

Fast TCP => NIC is not broken

Slow TCP => It is not SMB-related. FTP wont help either

Community
  • 1
usr
  • 245
  • 3
  • 11
0

The Exchange utility you're thinking of is probably esefile, the functionality of which has now been baked into the eseutil utility. "eseutil /y" is the switch you use. I haven't tested it against robocopy or the Vista copy utility, so I don't know if it actually still provides a speed advantage.

paulr
  • 2,083
  • 13
  • 11
0

I would consider using SyncBack. We use it to move up to 30 GB files over WAN with reasonable throughput for off-site backups. There are different versions of it some of which allow throttling the use of bandwidth, using native versus Windows copy and FTP.

0

There is a protocol for transferring files. It's called FTP. You may find that this works better for you than using network shares. (although other posters are right that you should get better throughput that you are doing over the network).

Jeremy French
  • 675
  • 3
  • 12
  • 25
0

The best file copy utility by far is Teracopy, from codesector.com I've been using it for years with XP, and find it works just as well in Vista. I agree with the other posters that something else is probably wrong in this situation, but to answer the original question, teracopy FTW.

Happy Hamster
  • 403
  • 5
  • 12
0

I've found that a single-threaded file copy tops out at around 40Mb/sec - consider using richcopy to do a multithreaded transfer.

user2278
  • 873
  • 5
  • 9
  • robocopy under Windows 7 and Windows 2008 R2 support multi-threaded transfer with the /MT switch uses 8 threads by default. – Richard Slater May 18 '09 at 18:45
-1

Use robocopy from the command line (including with Vista/Win7). This will provide progress reports and the ability to filter what is copied (and not copy files that have not changed).

Richard
  • 5,324
  • 1
  • 23
  • 20