Question about transfer rates / time

[Clive Staples]

Hey folks,

I have just put together a new build and as I was moving about 47 GB worth of files from a backup onto my C: volume, I noticed that the transfer time seemed longer than I would have expected.

It occurred to me that I've seen this before, too, on my previous rig - so maybe it's normal.

But I had this data - a lot of files making up the 47 GB - on an internal IBM SSD (can't remember if it's 520 or 530 but I can find out, if it matters). I was copying from the Intel SSD to my "Pictures" directory, as I recall, on my C volume, which is a healthy RAID 0 stripe consisting of a pair of Crucial RealSSD 300s. (I only kept my SSDs from the previous build - everything else is brand new.)

My new build is a Core i7 5930k on a GA-X99 Gaming 5 motherboard, with 16 GB of Adata DDR4 SDRAM DDR4 2400.

For some reason it took over an hour to transfer the 47 GB of data. Now I know that's a fair-sized chunk, but my transfer rate (at least according to the Windows file transfer dialog) started out fast and dwindled down to about 9MB/sec, where it remained for most of the operation.

Meanwhile of course, CPU usage was about 2% the whole time, and the multiplier stayed at 12 (about 1200 MHz). I'm not sure how much the CPU factors into this though.

I guess my question is - is that type of file transfer performance normal? If not, is there something I could be doing differently?

Thanks!

 

[Eximo]

Smaller the files the worse Windows performs at this type of thing.

So in reality everything on your system is stored in clusters, or concatenated sets of clusters.

If you have a 1KB file, it will likely end up in a single cluster by itself(64KB or whatever your actual size is, especially with a raid array)
After each file transfer it will then verify via checksum that it was done properly. So that also adds to the time.

CPU isn't much in use because the RAID controller pretty much handles it all internally without need for the CPU. CPU just gathered the list of files to be copied essentially.

If it were one contiguous file it would have transferred much faster. So next time, if you have the space, try zipping it up first.

Oh, another annoyance with Windows. It starts copying before it has finished counting files, and it doesn't do any type of file size/type check before creating it's initial estimate. Basically it starts out high because it seemingly accomplished a lot in the first few seconds and is comparing the amount of raw data vs the transfer speed available at the time. After that it starts integrating down to create a new estimate. This is why it always seems to get slower as it goes.

 

[Clive Staples]

Smaller the files the worse Windows performs at this type of thing.

So in reality everything on your system is stored in clusters, or concatenated sets of clusters.

If you have a 1KB file, it will likely end up in a single cluster by itself(64KB or whatever your actual size is, especially with a raid array)
After each file transfer it will then verify via checksum that it was done properly. So that also adds to the time.

CPU isn't much in use because the RAID controller pretty much handles it all internally without need for the CPU. CPU just gathered the list of files to be copied essentially.

If it were one contiguous file it would have transferred much faster. So next time, if you have the space, try zipping it up first.

Oh, another annoyance with Windows. It starts copying before it has finished counting files, and it doesn't do any type of file size/type check before creating it's initial estimate. Basically it starts out high because it seemingly accomplished a lot in the first few seconds and is comparing the amount of raw data vs the transfer speed available at the time. After that it starts integrating down to create a new estimate. This is why it always seems to get slower as it goes.

Excellent, that's exactly the kind of information I was looking for. Thanks for your help!