Why do I only get 24 MB/s throughput when copying files from a USB hard drive to my hard drive?

Question

I know this is normal and not a fault but why is the throughput so low when using a brand new 7200 RPM hard drive and a fast USB external drive?

I know there is some "overhead", but what is this overhead? Why is it so slow?

Answer 1

From USB 2.0, Hi-Speed USB FAQ:

When USB 2.0 introduced Hi-Speed USB mode, it boosted bandwidth to 480Mbit/s or 60Mbyte/s.
...
As for a lot of USB storage, burning a DVD-R at its fastest rate or 16x takes up 21MByte/s or 169Mbit/s. That translates to 35% of overall USB 2.0 speed. Hard drives, however, demand huge amount of bandwidth that USB 2.0 cannot meet; we've seen a USB 2.0 hard drive has sustained 36 to 40MBbyte/s in the absolute best scenario. USB flash drives have also reached 33MBytes/s, but there seems to be some limitations in the NAND itself so you shouldn't expect their speeds to skyrocket in a next year or two. For most consumers, there shouldn't be a problem with running out of bandwidth.

For speeds note the distinction between megabits and megabytes.

As mentioned above, throughput will depend on the size of the files and folder structure you're copying. If there's lots of files, or the process moving the files is doing some additional processing e.g. ZIP, the throughput will be much lower.

If you're copying a single large file (more than 1 GB) using Windows Explorer, you should see speeds approach 40 Mbytes/s but it will probably not exceed that due to USB protocol overheads.

As mentioned, check nothing else is active on the USB bus. Even a mouse use up a chunk of the available bandwidth.

Answer 2

A typical 7200 RPM SATA drive has a maximum transfer rate of 125 MB/s (example, Seagate Barracuda 7200.12).

So if you have the bandwidth, and you do nothing except read consecutive sectors with no seeking, you will get about five times faster than what you are seeing.

However, data is not contiguous even in a single file, and multiple files might be in multiple blocks. Further, each file write requires a change to the directory tables and/or FAT. Whether you're seeking because the file isn't contiguous, or you're seeking because you have to write to the file or directory table, you're going to eat up time in the seek.

An average seek time is around 8 ms, so you're eating up a LOT of time each seek.

Not only is this going on at the target drive, but the source hard drive must also seek around for the bits and pieces of each file and directory entry. It's probably worse at the source due to greater fragmentation (files are broken up into more pieces).

Also, each command must go over the USB. It's not a ton of overhead, but it's a 'dumb' mass storage device, so Windows says, "Hey, give me sector 4923847" and the drive complies. Then Windows asks for, or writes to another sector. With command queuing it's at least as efficient as it can be, but the USB interface is transferring a lot more than just the raw data you are copying.

The USB tops out at 480 Mbits/s, but the reality is that you are doing very well if you get 48 MBytes/s out of that interface, and it may be competing with your slower mouse, keyboard, and other USB peripherals. Depending on how the hosts and hubs are set up, and how cheap they are, you could be losing very significant USB bandwidth due to low speed peripherals chewing up time slots.

All of these factors combined say, essentially, "Wow, you're getting 24 MB/s? That's actually pretty good!"

Answer 3

24 MBytes/sec is pretty reasonable for a single-SATA -> single-SATA throughput regardless of interface. Especially if there are lots of small files (versus one big file), fragmentation on either disk, etc.

You can use IOmeter to test the maximum sustained read and write speeds for sequential reads and writes. You have to do a full defrag or work against a cleanly formatted partition to get an accurate test.