SATA HDD to HDD throughput issues

Greetings,

I have a question concerning the speed at which data is transferred between two of my HDDs. My config is as follows :

Win7/64 Ultimate
24GB DDR3 1600
source HDD : WDC WD20EARS-00S8B1
target HDD : ST3000VX000-1CU166
mainboard : Gigabyte Sniper-1

I have three other disks attached to the system, two of which are SDDs on which the OS is running. This is just to say that the source and target disk are not hampered by OS writes (normally).

Back history : I reinstalled my PC after fooling around with EASEUS Partition Master last week (my fault - not interesting here). After reinstall, I noticed that I was missing my main data storage partition.
So I install Partition Master again, check on my disk list, and find that my target HDD is now unallocated. I don't remember touching that disk at all in the Windows install procedure, so I try tinkering with a Partition Recovery tool, but that did not work.

In the end, I had to use a data recovery tool and Deep Analysis on the target disk. All data copied went to the source disk. Once I had recovered everything I really wanted, I repartitioned the target disk.

On my brand new partition, I started recopying the 650GB I had recovered. Initially, transfer started at around 80 MB/s and the GB numbers were going down in a satisfactory manner. I left the PC to go do other things and when I came back an hour later, transfer rate was down to an average of 7MB/s.

I checked the SATA driver on the mainboard installation disk, I checked for updates on Gigabyte's site, installed the update, rebooted and restarted. Same thing happened : initial rate was around 80MB/s, fell to 7 after about ten minutes.

I took me two days to finalize the transfer.

My question : is this normal ?

Pascal.

I've got nothing to hide, and I'd very much like to keep that away from prying eyes.

 

[cdogg]

No, it's not normal. Any hard drive manufactured in the last 5 years should easily be able to sustain 50 MB/s transfer rates, if not much higher. At the conservative 50 MB/s, it would only take roughly 3.5 hours. Two days is way, way off.

Since you recently reinstalled the OS, go to Gigabyte's website and download the latest drivers. Grab all of them and install one by one, but at the very least, I would install the SATA Controller drivers. Maybe your system is using a generic SATA driver now, and a more specific one from the vendor will speed things up.



-Carl
"The glass is neither half-full nor half-empty: it's twice as big as it needs to be."

[tab][navy]For this site's posting policies, click [/navy]here.

 

[goombawaho]

If no love with the above, I would remove all hard drives except one and test it using the manufacturer's diagnostic tool to make sure it's not dying.

You can also use a benchmark test for the drives.
Just one example Link

Note that your Western Digital drive is only SATA2 (WD20EARS) But, it should still be faster than what you experienced.
Link

"Living tomorrow is everyone's sorrow.
Modern man's daydreams have turned into nightmares.

 

[pmonett]

Okay, I got the HD Tune utility and used it.

Benchmark result (read only) for my target disk :

Average transfer rate : 157.1 MB/s
Access Time : 15.2 ms
Burst rate : 220.2 MB/s

Benchmark result (read only) for my source disk :

Average transfer rate : 84.7 MB/s
Access Time : 20.4 ms
Burst rate : 175.9 MB/s

These figures seem to me to be perfectly acceptable for SATA drives. Unfortunately, they do not explain anything.

I would need to get the data off the target disk to do the write tests. I just might do that one day.

Thanks for tip anyway. I have two other brand-new disks I will test, plus a half-dozen others I'd like to test. I'll be spending some time with this utility .

Pascal.

I've got nothing to hide, and I'd very much like to keep that away from prying eyes.

 

[cdogg]

Still doesn't make sense that the speed starts out somewhat fast and then slows to a crawl.

Out of curiosity, how are you initiating the file copy between drives? Are you sitting at the PC using it's keyboard/mouse, or are you remoting in over the network using the UNC path (i.e. \\targetpc\c$)? If you're sitting at the PC, are you simply selecting all the folders/files from the root, selecting copy, and then pasting them on the other partition? What happens when you only transfer a small portion?



-Carl
"The glass is neither half-full nor half-empty: it's twice as big as it needs to be."

[tab][navy]For this site's posting policies, click [/navy]here.

 

[goombawaho]

Still doesn't make sense that the speed starts out somewhat fast and then slows to a crawl.

Agreed. Points to something within Windows gumming up the works.

I would boot to a Linux CD or Bart PE or Windows PE CD and try a similar copying test to rule out the Windows factor. Yes, Bart PE or Windows PE IS based on Windows, but it's very stripped down with no anti-virus or extra programs running.

"Living tomorrow is everyone's sorrow.
Modern man's daydreams have turned into nightmares.

 

[pmonett]

Thank you for your interest cdogg. I know that you are a reliable member here and I respect your opinion.

I therefor reinitiated a copy between target and source to get an idea of the performance. Of course, this is all happening on the same PC, I do not have the skills to do remote anything on my PCs, even though I have a total of 6 PCs on my home network. Actually, when I install Windows on anything, my first act is to go through the services and disable anything that allows remote access to the PC.

So I restarted a move of 149GB to get an idea. Speed started at around 180MB/s, total time estimated 13 minutes.
Two minutes later, speed is down to 40MB/s estimated 1 hour (139 GB left).
Another minute and speed is down to 32.2 MB/s (135 GB left).

Interestingly enough, after 10 minutes, transfer speed was still 28.6 MB/s (121 GB left). After 30 minutes the rate was 25.4 MB/s (68.3 GB left).

So, this time the rate remained at around 25 MB/s, whereas before it was 7 MN/s.

I guess that another reboot was required.

Pascal.

I've got nothing to hide, and I'd very much like to keep that away from prying eyes.

 

[zelgar]

Some things you might want to check:
1. Try to defrag your HD's. If the data is all over the place, it may take longer for the data to be moved.
2. Since you are MOVING the data, it needs to be COPIED to the new HD and DELETED from the old HD.
3. One option you may wish to try is to create a RAM drive (you have 24 gigs of RAM) and go from HD 1 - RAM Drive - HD2. You may find out this is faster or that it's one of the HD that's taking forever and is the source of the problem.
4. Are either HD near their maximum capacities? If so, that may be hampering your speeds.
5. Shut down any other programs running on the PC OR boot up in SAFE MODE and MOVE the file

 

[goombawaho]

I'm not chopped liver - try my suggestion next. It will rule Windows out as the problem source.

"Living tomorrow is everyone's sorrow.
Modern man's daydreams have turned into nightmares.

 

[cdogg]

Agree with Goom. Let's rule out Windows next. In addition, it would be a good idea to make sure your system partition (C has plenty of free space and isn't running short. Zelgar makes a good suggestion too about fragmentation. That shouldn't be a problem on your target drive, but it could be a factor on the source drive. Go ahead and defrag it, even if Windows suggests that it's not needed.

Oh, and by the way...

Your source drive didn't get the best stats in the benchmark. Those numbers are barely average. That shouldn't cause the transfer to crawl, but it's worth keeping in mind. The WDC WD20EARS drive is the Western Digital Caviar Green model, which isn't optimized for performance. It uses what WD brands as "Intellipower", meaning it fluctuates between 5400 RPM and 7200 RPM in order to be energy efficient. Again, it's not likely the cause, but it could be a factor.

-Carl
"The glass is neither half-full nor half-empty: it's twice as big as it needs to be."

[tab][navy]For this site's posting policies, click [/navy]here.

 

[goombawaho]

Thank you. The one thing for certain that I've heard is that we still don't have any idea about the cause. A slow down is always possible during a copy especially if you hit a bunch of small files, but not to the extent experienced.

"Living tomorrow is everyone's sorrow.
Modern man's daydreams have turned into nightmares.

 

[pmonett]

Performance test update :

For various reasons I purchased Ramdisk during the XMAS holidays. I decided to use it to test throughput on my two disks.
So I arranged 21 files totaling 7.17GB on the source disk. Then I set my Ramdisk size to 9GB (out of 24). When I copied the files to the vdisk, speed started at 250MB/s and never dropped below 180. The copy was done in 30.68 seconds (timed with the Stopwatch app on my phone).
Copying the files to the target disk took a bit longer. Speed started initially at 1GB/s but dropped dramatically down to 150MB/s. After five minutes, speed was at 17MB/s, dropping slowly down to 12MB/s at the end. Total copy time was over ten minutes.
Out of curiosity, I deleted the files from the vdrive and recopied the files back to the vdrive from the target disk. The operation was completed in 22.42 seconds - I didn't have the time to get a proper average of the speed which displayed anywhere from 500MB/s to 100MB/s and back to 400.
I then did a physical copy of the files from the source to the target disk. Speed started at 148MB/s, rose to 180 but then dropped to 100 in the span of a minute. Total copy time estimated at 9 minutes, speed dropped to 13MB/s at its lowest.

To me, these results clearly indicate that read speeds are indeed at SATA levels. Write speeds are not.
Now I need to find time to download an ISO of some distro and do the same tests like goombawaho suggests.

I will keep you informed.

Pascal.

I've got nothing to hide, and I'd very much like to keep that away from prying eyes.

 

[goombawaho]

Good testing. There is a large list of bootable CDs available.
Link

"Living tomorrow is everyone's sorrow.
Modern man's daydreams have turned into nightmares.

 

[pmonett]

Thanks for the link, Goombawaho, I'll be looking into that shortly.

Oh, and I rather like chopped liver

I've got nothing to hide, and I demand that you justify what right you have to ask.

 

[goombawaho]

Actually I don't but you know it's an idiomatic expression.

"Living tomorrow is everyone's sorrow.
Modern man's daydreams have turned into nightmares.

 

[pmonett]

Okay, final note on this subject.

I have installed a NAS based on a Synology DS414j with 3 3TB disks in Raid 5. The NAS and all computers are on a GB LAN with a GB switch.

When transferring files to the NAS, I have found that large files (over 1GB in size) transfer at a minimum of 60MB/s going up to 85, while numerous small files (less than 100KB) transfer at speeds much, much smaller (around 1.5MB/s when all goes well).

So, when transferring a large (several thousands) batch of small files, bandwidth is visibly impacted by the amount of management required to store them - whereas large files are apparently easier to file thus transfer more quickly.

Given that the NAS is operating under a LINUX distribution, it appears clear that Windows is not at fault in the transfer speeds I experienced.

Thank you for your support,

Pascal.

I've got nothing to hide, and I demand that you justify what right you have to ask.

 

[goombawaho]

A simpler way to think about it:
SATA 3 speed limit = 600MBps
Fast SSD speed limit = 500MBps
Western Digital Velociraptor = 200MBps

So, that is just with one device involved. Adding a NAS device and network cabling with TCP/IP overhead and computer on the other end is bound to slow things down. How slow/fast is "all you can get depends" on a lot of things.
Link

"Living tomorrow is everyone's sorrow.
Modern man's daydreams have turned into nightmares.