• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 660
  • Last Modified:

USB Drive very slow

I have two identical, new, WDC WD30EZRX-00DC0B0 external, self-powered 3TB USB drives connected to each of 2 of what are supposed to be the USB 3.0 ports on my Gigabyte Technology GA-78LMT-USB3 motherboard. My system is running Linux Slackware version 13.37.0, kernel

Copying from one drive to another seems very, very slow. It takes about 8 hours to copy a 190G file.

On the port closest to the mother board, initial command line pathname completion takes 20+ seconds. ls -ltr initiall takes 25+ seconds. likewise, df takes 15-ish seconds to return

On the port above that one pathname completion and ls are instantaneous.

By contrast it only took 4 hours to copy over 400GB to an identical USB drive on another computer (although not copying between USB drives).
Does 8 hrs for 190GB this seem reasonable for copying between USB drives?

Should both drives not be plugged into the same bus?

Does this seem like a problem with motherboard, drive?
  • 3
2 Solutions
After running a benchmark test on 2 different 3TB usb3 WD external drives (both of them 3.5" drives that are not self powered though) that I get around 135 MB/s on both SEQ read and write speeds. I'd have to do a bit more research before knowing if your release of slackware natively supports 3.0 since I haven't used slack since Backtrack switched to debian, but I would say there is a definite issue with your software. Your drives might be a bit slower since they are pulling power from the usb port itself but no way would it be that significant of a loss.
jmarkfoleyAuthor Commented:
Hardware_Guy: > Your drives might be a bit slower since they are pulling power from the usb port itself

The drives are self powered, not powered from the hub, so that shouldn't be a factor. According to my research, Linux has supported USB 3.0 since kernel release 2.6.31. This kernel is, so USB 3.0 should not be a problem. The mother board is new, purchased this summer.

I have determined that it is not the drive. I swapped out the drive that was taking a looong time to give me the `ls` listing, and replaced it with the drive from the different machine that apparently managed to copy 400GB in 4 hours (on the same version of Linux). Unfortunately, the looong `ls` and `df` times persisted. Interestingly, the "slow" drive is the one being read from, not the one being written to. I would think it should be the other way aroundI am running a copy right now to see if the files copy faster, but I'm not hopeful.

Could there be an issue with read/writing from/to drives on the same USB hub? Perhaps I should switch one of the drives to a different hub (which would be USB 2.0).

jmarkfoleyAuthor Commented:
Well, I believe I've solved the problem. I moved the source USB drive to a different bus which is 2.0, and left the destination drive on the 3.0 bus. I reasoned that the one getting written-to would likely have more I/O activity than the one only being read-from.

New results: 100GB transferred in about an hour! So, 4 times faster than both drives plugged into the same USB 3.0 bus. I believe my theory about not having the drives on the same bus is correct. I don't think it is an OS thing.

This link confirmed my opinion: http://h30565.www3.hp.com/t5/Feature-Articles/How-To-Fix-Slow-USB-Connections-and-Devices/ba-p/8224

"#6. Avoid copying on the same bus

Today’s mainboards, both on desktop PCs or laptops, sport more than one USB controller. If you’re suffering from bad performance when copying from USB device to device, you should avoid connecting two devices to the same port."

This article also links to a Linux USB benchmark utility, which I haven't tried, but will keep for future reference: http://www.roylongbottom.org.uk/linux_disk_usb_lan_benchmarks.htm
jmarkfoleyAuthor Commented:
Hardware_Guy - thanks for participating!

EE: I solve the problem myself
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Train for your Pen Testing Engineer Certification

Enroll today in this bundle of courses to gain experience in the logistics of pen testing, Linux fundamentals, vulnerability assessments, detecting live systems, and more! This series, valued at $3,000, is free for Premium members, Team Accounts, and Qualified Experts.

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now