Poor system responsiveness when doing large USB transfers

[Dangermouse]

So ... what you are saying is that your system slows to a crawl when you are copying data thru a USB 1.1 port ?

Yeh unfortunately so i dont use them, also found a difference on what cable i use, no ideal why though!

[dd_wizard]

I used stevea's "sleep; cp" trick to get back to the gui before the copy started. The results were odd. X ran fine; I could alt-tab between windows, click different windows in the task manager, etc. However, when I switched to the Firefox window, it was basicly locked up. Changing tabs took forever. And it was impossible to type this reply until the copy finished. But as I said, X was only slightly affected. Any ideas what's up?

dd_wizard

---------- Post added at 03:42 PM ---------- Previous post was at 03:40 PM ----------

The lag seems to appear after the write buffer is filled. Not sure if that helps.

dd_wizard

[jpollard]

That makes (possibly a large) part of the issue an I/O and buffer problem - Firefox is known to have a large memory footprint, and it may be starved for buffer space/paging.

X is nearly all memory resident and a bit of a CPU pig.

Not sure which parameters could be tweaked for this behavior though.

I did run across an I/O performance issue with USB (echo 1024 > /sys/block/sde/device/max_sectors) changes the amount written at a time, this MAY affect things if the controller is blocking to the device as it would free up more memory on each write. "sde" here is the specific disk attached to a USB. This is from http://marc-abramowitz.com/archives/...ives-in-linux/ which is 4 years old though.

[flyingfsck]

Howdy,

I also saw this when trying to format a USB memory stick with mkfs.ntfs. The default action is to overwrite the whole device with zeroes - a big mistake - took forever and locked up things for the duration.

[pablow]

I'm seeing the same issue. I was wondering also if this problem affects audio playing when a high I/O task is beeing executed.

[jpollard]

It should... Though the I/O will be the disk reads of the data. I don't think the short buffers sent to the audio device would have much of an effect, but reading data from disk would certainly get affected.

[pablow]

Wow, net download speed drops down from 400KB/s to 50KB/s when doing a usb transfer or mkvmerge

EDIT: Sorry, random download speed, I can't atribute to this issue.

[DBelton]

I also experienced a big slowdown in transfers to a USB drive. Good thing I rarely use USB drives here.

Dropped from an average of 27MB/sec to 6MB/sec. This was on update to F15. F14 worked fine. (Don't have a USB drive on my F16 system at the moment to see if it's still an issue there, but will try and check it later)

Interesting.. Doesn't seem to have affected a drive attached via firewire (on F15). Getting about 37MB/sec there read and write.

[pablow]

Any news? Here in Fedora 16 the behaviour remains the same. It's very very annoying

[DBelton]

I have found something very interesting.

I have 2 F16 machines, pretty much set up identical except one is running 64 bit, the ohter is running 32 bit PAE kernels.

Using the very same 2TB external hard drive, both machines have USB 2.0 ports which the drive was plugged into for this test.

On the 64 bit machine, My transfers were around 39MB/sec over a 500GB transfer. (Fresh drive, nothing else on it.)

Delete those files off the drive, plug it into the 32 bit machine. (checked to make sure the same mounting options were being used). The transfer dropped to around 5MB/sec on the same file transfer.

Source drives were identical WD Caviar black drives, both get about a 128MB/sec sustained transfer rate, so the source drive isn't the issue.

While I could see a small difference in transfer rates, this is a HUGE difference. (about a 35MB/sec difference) and yes, I did make certain that the USB port and drive were seen as USB 2.0 and not 1.1