Resurrecting a thread: slow usb write speeds

I am seeing slow writes to a usb 2.0 HDD on ubuntu 9.04. The thing is that when first installed, and off the livecd, I see speeds of 15+MB/s, but now (a few days later) I can only get speeds starting at about 5MB/s trailing off to 1.5MB/s sustained (this is copying around 700+MB avi files)

Now. This thread:
http://www.linuxquestions.org/questi...slow+write+hdd

Is discussing exactly that issue, but got closed by a moderator just as it was getting interesting. I can't post to the moderator (pixellany) to reopen the thread, cos I am a newbie, and I need at least one post to activate that functionality I think.

This is that post I hope; but while I'm setting to reopen that thread - any ideas?

Hi welcome to LQ!

This is that post I hope; but while I'm setting to reopen that thread - any ideas?

And yes, of course:

Why don't you post *your* answers to the questions that were posed then?


Cheers,
Tink

Originally Posted by Tinkster Hi welcome to LQ! And yes, of course: Why don't you post *your* answers to the questions that were posed then? Cheers, Tink

Touche.

My configuration is ubuntu jaunty (9.04) on a Sony Vaio G11 (2GB, Intel core solo U1500; Intel 950 graphics chipset) dual booting to win XP. Trying to use a 500GB USB2.0 (NTFS filesystem) to store videos and largish backups.

On the thread in question, rkelsen had suggested a change to the scheduler:

### quoted - cut and paste (i'm new here) ###

Seeing this behaviour between hard disk partitions would indicate that the default scheduler may not be best for your needs. Your config files indicate that the CFQ scheduler is the default on both kernels.

I'll explain how to change it now, because I'm going to bed shortly...

The output of the command in the previous post should look something like this:
Code:

$ cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]

In this case, the noop, anticipatory, deadline and cfq schedulers are available for sda, and the brackets indicate that the cfq scheduler is currently selected.

The way to change it would be: (again substituting sda for the USB device)

Code:

# echo anticipatory > /sys/block/sda/queue/scheduler

You need to run this as root for every block device you wish to change.

### end quoted ###

This appears to have fixed uncertains usb drive, but not his other drives.

NB: uncertain discovered that other devices/partitions - not just usb - were affected. I have found the same - having been clued to check that by the thread. My write speed copying a file to the boot filesys is 1.5MB/s - usb 1.1 speeds, and this is the native boot HDD, NOT a USB device.

rkelsens opening suggestion does not work for me. It worked for uncertains USB HDD, but not his other partitions when the question became moot - a kernel upgrade fixed the issues for him.

At this point the thread was closed (28 july 2009 - a month ago)

I have upgraded to 2.6.30-02063003-generic (intel graphics chipset issues - largely resolved)

Posting this in case anybody gets here.

In my case the situation is a lot more complex than it looks: The root of the trouble is a cheap/failing USB2.0 HDD enclosure.

On windows XP the faulty enclosure mounts fine and write speeds of 10MB/s are seen.

On ubuntu jaunty the faulty enclosure mounts with some retries (dmesg) and slow writes of a few MB/s falling to 1.5MB/s steady-state are seen.

Thats on a good day. On a bad day:

On windows XP the faulty enclosure mounts fine (though it seems to take a sec or so longer); but is no longer discovered at XP startup. It has to be unplugged-replugged to be mounted.

On ubuntu, the device is discovered but no longer recognised. dmesg shows several failed mount attempts. force mount and fixntfs cannot be made to work as it fails to have an sdb mount assigned to it. It is not seen as any kind of storage.

This was discovered by swapping HDDs between two USB2.0 enclosures. The "faulty" enclosure exhibits the same behaviour with either HDD, and the other enclosure works just fine, no ntfs dirty bits or anything.

This all became clear on a bad day for the enclosure. What makes this difficult to figure is that once the bad enclosure has been plugged in and written to at it's slow speeds, then the good enclosure is written to at that slow speed as well. A restart is necessary to get it back up to speed.

NB: The good enclosure gives write speeds of 17-18 MB/s, much better than windows.

Looking at dmesg, I see the optical mouse being lost and rediscovered with "(EMI?)" in the message. This is with the faulty enclosure, so there may be a lot of noise coming from this unit. That would pretty much explain everything, except why it works at all

I hypothesize that the usb driver falls back to slow speeds, maybe even 1.1 mode, in the presence of a lot of errors (noise), but makes no attempt to recover performance if the noise source is removed. There is no indication of this process in dmesg.

Presumably dmesg is to do with discovery and termination. Is there another log I can look at telling me about ongoing state changes in the USB drivers?