Sign in with
Sign up | Sign in
Your question
Solved

usb 2.0 ports S L O W W W W

Last response: in Motherboards
Share
September 11, 2013 9:58:00 AM


My "new" ASUS M2Ne mainboard was installed after a few years of storage, and all seems OK except for a sudden drop in USB 2.0 port speed. Days ago, I made a full image of my system at a normal USB 2.0 write rate of over 200 Mbps (using Macrium Reflect 5.2) and completed the image successfully in slightly over two hours.

Only days later, however, the same operation took almost six times longer (12 hours+), and consistently at a data rate of 29 Mbps, still using Macrium Reflect 5.2. This slow rate did not change when I switched to Acronis TrueImage Home 2011 for the same operation.

Nor did the data rate improve when I switched to another, identical model of external USB drive, and used another, identical and well-tested USB data cable, each component in good condition (each has made images at 200 Mbps). In fact, both USB external drives and both USB cables have been used to make an image at the faster, 200 Mbps+ rate.

No other changes on this system were made between the dates of the two backups, except for the possibility I installed (REinstalled) a driver from the mainboard drivers DVD (nVidia chipset nForce 570 Series). And because installation of the nForce Network Access Manager failed twice with errors during
the attempted installation, it seems possible some files may have been corrupted-- but I have not found any.

Although the nForce drivers DVD had a menu item to install "USB2.0 Drivers", on clicking that option, I was advised Windows XP SP1+ already has the appropriate driver, so I did not proceed.

So, all USB 2.0 drivers for storage on this system are from Microsoft, dated 7/1/2001 for the "USB Root Hub" and the "Standard OpenHCD USB Host Controller" drivers, and dated 6/1/2002 for the Standard Enhanced PCI to USB Host Controller driver. Following standard procedure with such USB problems, I have
uninstalled, then reinstalled (on boot) the current USB drivers set.

And, yes, all drivers listed under my system Device Manager / Universal Serial Bus Controllers now display "This device is working properly". The Microsoft Troubleshooting module has been of little help, in this case.

Although the 480 Mbps speed for USB2.0 is a theoretical maximum, it confirms my high expectations for USB2.0 when I attach my external USB2.0 drive to another machine with USB2.0, and it regularly turns in a writing data rate around 200 Mbps.

Operating system-- MS Windows XP Professional 32
RAM-- 2 GB
CPU-- AMD Athlon64 X2

More about : usb ports

Best solution

a b V Motherboard
September 11, 2013 11:21:59 AM

I have 3 USB 2.0 drives that all read/write about 30mb/s, so it looks normal too me. I have seen them go up to 200, but that was only because the system had what I wanted to copy cached. Near the end of the transfer it would slow down considerably until the drive was caught up then it would finish. It would appear that the transfer was about to complete, but it would hang there for a long time before finishing completely.

That is probably the issue here, since only USB 3.0 devices can handle that kind of speed right now...
Share
September 11, 2013 8:02:28 PM

sincreator said:
I have 3 USB 2.0 drives that all read/write about 30mb/s, so it looks normal too me. I have seen them go up to 200, but that was only because the system had what I wanted to copy cached. Near the end of the transfer it would slow down considerably until the drive was caught up then it would finish. It would appear that the transfer was about to complete, but it would hang there for a long time before finishing completely.

That is probably the issue here, since only USB 3.0 devices can handle that kind of speed right now...


Thanks for your response.

I have run USB external drives a long time under USB2.0, and a speed of 200+ Megabits Per Second is within a normal distribution for writing on my system. That said, the issue is the sudden and dramatic drop in speed, since none of my routine imaging sessions ever has required much over three hours, and the new mainboard and new CPU reduced the time on several occasions to around two hours-- before the drop in speed.

That speed restriction has been consistent since it began, and rarely varies from 28-30Mbps in the writing phase, rendering what was once a two-hour imaging session into a 12-hour ordeal.
m
0
l
October 7, 2013 8:03:11 AM

FINALLY, THE REST OF THE SOLUTION--

While tweaking the USB2.0 external (target) drive settings for my system backup, I had changed Properties for the external drive from "Optimize for Quick Removal" to "Optimize for Safe Removal". I was unaware that my "safer" setting would leave my transfer speed completely unacceptable.

Only later did I discover that altering the option from quick to safe removal had reduced the transfer speed by a factor of six or more. Mysteriously, during earlier testing, I had rechecked this setting for its effect on speed, but for some reason it was not apparent at that time.

Now, with its cache restored, the external drive's faster speed has returned-- on this Windows XPPro system with an Athlon 64 X2 and only 2GB of memory, I get 180.6 Mbps write speed from a normal source drive to the external drive. That could reduce the former 12-hour system backup to a tolerable 2.5 hours.

Yet, there was still another cause for the slow USB2.0 data rate during an imaging operation-- a failing source drive. Logically enough, when I included that source drive with its hidden performance problems in a backup, the failing drive reduced the data rate to a fraction of normal, even after having corrected cache settings on the target drive. And when combined with two normal source drives, the failing drive acts as a bottleneck on over-all imaging speed.

Having established proper cache settings for the target (external) drive, and isolated a failing source drive, it was now clear that running a test of each of the other source drives might isolate still other problems. So, I tested separately each of the remaining two physical drives that normally contribute data to the typical system image. The transfer speed for two normal source drives running under cache was roughly similar, and completely acceptable.

Now, my task is to remove all data while I can from the failing Seagate drive, restore the data to a new host drive, and test that new drive separately from the other two source drives to make sure a normal data rate applies during imaging operations.
m
0
l
!