Really slow USB HD performance

Hi Guys,

I just tried to attatch my USB harddisk to my Pi over a powered hub but the performance is abysmal:

Code: Select all

root@raspi:~# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   276 MB in  2.00 seconds = 137.84 MB/sec
 Timing buffered disk reads:  12 MB in 32.44 seconds = 378.84 kB/sec


a USB stick at the same hub connected at the same time gives this:

Code: Select all

root@raspi:~# hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads:   276 MB in  2.01 seconds = 137.13 MB/sec
 Timing buffered disk reads:  76 MB in  3.07 seconds =  24.79 MB/sec


i also got this in dmesg:

Code: Select all

[ 1237.547035] usb 1-1.2.4.2: reset high speed USB device number 7 using dwc_otg
[ 1276.717993] usb 1-1.2.4.2: reset high speed USB device number 7 using dwc_otg
[ 1277.047990] usb 1-1.2.4.2: reset high speed USB device number 7 using dwc_otg
[ 1277.347997] usb 1-1.2.4.2: reset high speed USB device number 7 using dwc_otg
[ 1307.778810] usb 1-1.2.4.2: reset high speed USB device number 7 using dwc_otg


I'm using the kernel

Code: Select all

3.1.9+ #144 PREEMPT Sun Jul 1 12:37:10 BST 2012

I'm using the raspbian distro. I also tried with the Raspian kernel and i couldn't even mount the HD.
dmesg was getting flooded:

Code: Select all

[ 4140.873166] usb 1-1.2.4.2: new high-speed USB device number 8 using dwc_otg
[ 4142.632131] usb 1-1.2.4.2: New USB device found, idVendor=174c, idProduct=5106
[ 4142.650200] usb 1-1.2.4.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 4142.668634] usb 1-1.2.4.2: Product: AS2105
[ 4142.683473] usb 1-1.2.4.2: Manufacturer: ASMedia
[ 4142.698793] usb 1-1.2.4.2: SerialNumber: 100925PBN306GTKH3MHS
[ 4142.729509] scsi1 : usb-storage 1-1.2.4.2:1.0
[ 4143.776555] scsi 1:0:0:0: Direct-Access     HITACHI  HTS545032B9A300  PB3Z PQ: 0 ANSI: 5
[ 4143.806186] sd 1:0:0:0: [sda] 625142448 512-byte logical blocks: (320 GB/298 GiB)
[ 4143.846795] sd 1:0:0:0: [sda] Write Protect is off
[ 4143.862289] sd 1:0:0:0: [sda] Mode Sense: 23 00 00 00
[ 4143.883674] sd 1:0:0:0: [sda] No Caching mode page present
[ 4143.899803] sd 1:0:0:0: [sda] Assuming drive cache: write through
[ 4143.924782] sd 1:0:0:0: [sda] No Caching mode page present
[ 4143.940850] sd 1:0:0:0: [sda] Assuming drive cache: write through
[ 4144.000297]  sda: sda1 sda2
[ 4144.026808] sd 1:0:0:0: [sda] No Caching mode page present
[ 4144.042825] sd 1:0:0:0: [sda] Assuming drive cache: write through
[ 4144.059391] sd 1:0:0:0: [sda] Attached SCSI disk
[ 4203.684582] DEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACK
[ 4203.684603]
[ 4203.714332] DEBUG:handle_hc_chhltd_intr_dma:: XactErr with NYET/NAK/ACK
[ 4203.714352]
[ 4203.745832] DEBUG:handle_hc_chhltd_intr_dma:: XactErr with NYET/NAK/ACK
[ 4203.745852]
[ 4203.775705] DEBUG:handle_hc_chhltd_intr_dma:: XactErr with NYET/NAK/ACK
[ 4203.775725]
[ 4203.805407] DEBUG:handle_hc_chhltd_intr_dma:: XactErr with NYET/NAK/ACK
[ 4203.805428]
[ 4203.835281] DEBUG:handle_hc_chhltd_intr_dma:: XactErr with NYET/NAK/ACK
[ 4203.835301]
[ 4203.865155] DEBUG:handle_hc_chhltd_intr_dma:: XactErr with NYET/NAK/ACK
[ 4203.865175]
[ 4203.896718] DEBUG:handle_hc_chhltd_intr_dma:: XactErr with NYET/NAK/ACK
[ 4203.896739]
[ 4203.926479] DEBUG:handle_hc_chhltd_intr_dma:: XactErr with NYET/NAK/ACK

snip

[ 4222.821828]
[ 4222.851580] DEBUG:handle_hc_chhltd_intr_dma:: XactErr with NYET/NAK/ACK
[ 4222.851601]
[ 4222.881302] DEBUG:handle_hc_chhltd_intr_dma:: XactErr with NYET/NAK/ACK
[ 4222.881325]
[ 4222.910965] DEBUG:handle_hc_chhltd_intr_dma:: XactErr with NYET/NAK/ACK
[ 4222.910987]
[ 4222.911124] DEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACK
[ 4222.911138]
[ 4222.970443] DEBUG:handle_hc_chhltd_intr_dma:: XactErr without NYET/NAK/ACK
[ 4222.970462]
[ 4223.030687] usb 1-1.2.4.2: USB disconnect, device number 8
[ 4223.078050] scsi 1:0:0:0: [sda] killing request
[ 4223.093516] scsi 1:0:0:0: [sda] Unhandled error code
[ 4223.109288] scsi 1:0:0:0: [sda]  Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[ 4223.128023] scsi 1:0:0:0: [sda] CDB: Read(10): 28 00 00 40 0b d8 00 00 08 00
[ 4223.146230] end_request: I/O error, dev sda, sector 4197336
[ 4223.162631] Buffer I/O error on device sda2, logical block 123


until I unplugged the drive.

What's the matter with this?
I was planning on using this drive as external root drive.

Regards
Aydan

Have you tried the hard drive connected to another computer via the same hub? and/or with a different power supply to it just to eliminate possible causes.

First of all how long is the cable to your USB HDD?
If it is more than 18" (.5m) then it could be a power problem. Is it a "Y"? Taking power from two ports on your hub. USB HDD's use up to 4watts while running. 1 port at 500ma supplies only 2.5 watts. Is it a USB 2.0 cable? What is the RPM of the drive? 3600, 4500 or 5400?
I know, a lot of questions, but all have an effect on its performance.
Best
5400 RPM
18" or less cable
"Y" cable 2 power leads.
USB 2.0
My HDD is slighly slower than the SD card in use but allows a better swapfile and setting for an overall performance gain.

The cable is about 30cm, it came with the enclosure and works perfectly with the same hub and the same cables on my PC (Win7-64).
See CrystalDiskMark performance here:

usb-hd-perf.png (55.32 KiB) Viewed 4632 times

I was also getting problems with my bluetooth dongle and a usb stick. Is seems the USB-stuff is still rather unstable.
The HUB is a powered BELKIN 7-port travel hub.
I checked it with a current Debian live CD and the hub doesn't make problems with that. I didn't check with the HDD though, only the usb stick and the bluetooth dongle.

Regards
Aydan

Code: Select all

hdparm -tT /dev/sda
/dev/sda:
 Timing cached reads:   274 MB in  2.01 seconds = 136.48 MB/sec
 Timing buffered disk reads:  56 MB in  3.04 seconds =  18.39 MB/sec


and pretty much the same for the SD card

378KB/s pretty slow. How are you on updates
?
Sudo uname -a
I am about a week behind and I am at preempt 138.
If you have not used rpi-update you might give it a try. There is a new bootcode.bin also, but I have not really had speed problems with the USB HDD since preempt 8.

Firmwarewise I'm up to date.
I've been using the rpi-update script.
At the moment i'm using the Raspbian alpha kernel, which seems to be more problematic in this regard. Otherwise i use the 3.1.9 kernel that came with the raspbian pisces r2 image.

Regards
Aydan

I've been using an iPad charger and it powers my wireless mouse, apple two port USB hub keyboard with a wifi dongle, it all works fine- I've clocked it almost to the max. So I doubt it's the power supply!

I am looking at similar USB HDD performance numbers, using a powered Trust 7p USB hub and a WD 320 GB USB-HDD.
The one thing that strikes me is that running the RPi RootFS from the USB-HDD, very often a commandline entry sits there for several seconds doing nothing while the HDD activity LED shows drive access. I do not have a swapfile active, still sufficient MBs of DRAM available.
I do not experience this same phenomena running the RootFS from the SD card.
BTW: I am using rpi-update to keep track, currently on Debian 3.1.9+ #152. The USB-HDD runs fine on a desktop Debian platform.

I just did a test after again reading from lots of people having problems with their USB-hubs.
I used a Y-cable to power the HDD from the hub but connected the data directly to the RasPi, et voila, no problems.
I'm getting 20+ MB/s from my HDD and from the USB-Stick as well.
I suppose my hub is one of those that don't work
I hope the driver guys can get this fixed soon.

Regards
Aydan

Thanks for the tip, Aydan!

I also had both ends of my y-connector plugged into my powered USB hub, and was receiving a ton of "reset high speed USB device" errors. Connecting the data cable directly the the Pi got rid of the errors, and greatly increased my transfer speeds.

Glad I could be of help, plasticbrain

I did a few more tests with respect to this and had a few interesting findings:
- my 7 port hub is indeed 2 staggered 4 port bubs.
- if i connect my mass torag to the first level hub, I get good performance and no USB reset messages in dmesg.
- if i connect mass storage to the second level hub, I get bad performance with USB reset messages.

Here's some logs:

USB debug.zip

(11.49 KiB) Downloaded 85 times

I hope this helps debugging the USB issue some more.

Regards
Aydan

I hate to necro old posts, but is there a centralized place with performance metrics of various SD Cards and Hard Drives (or SSDs) used on the Pi?

Strictly from a performance standpoint, my SSDs are pretty fast in Windows (60GB Corsair Force 3 & 480GB Corsair Force GT) so I'm considering the use of an SD Card containing /boot while the OS itself resides on an SSD, and I'd like to know if there is enough of a performance increase to make it worth while.

Additionally, how much more difficult is it to perform upgrades when the media is split like this?

I hate to necro old posts, but is there a centralized place with performance metrics of various SD Cards and Hard Drives (or SSDs) used on the Pi?

Not that I know of.

Strictly from a performance standpoint, my SSDs are pretty fast in Windows (60GB Corsair Force 3 & 480GB Corsair Force GT) so I'm considering the use of an SD Card containing /boot while the OS itself resides on an SSD, and I'd like to know if there is enough of a performance increase to make it worth while.

I guess it is a case of trying it to see. I have tried running of a USB stick and also off a USB connected HD, and both of these perform better than running of the SD. What improvement a SSD might give I have no idea, and I do not have a spare one to experiment with

Additionally, how much more difficult is it to perform upgrades when the media is split like this?

This is not an issue. You specify in the cmdline.txt file on the SD card boot partition where the root partition is located, and when updating the software always updates the current root partition.

I hate to necro old posts, but is there a centralized place with performance metrics of various SD Cards and Hard Drives (or SSDs) used on the Pi?

Not that I know of.

Strictly from a performance standpoint, my SSDs are pretty fast in Windows (60GB Corsair Force 3 & 480GB Corsair Force GT) so I'm considering the use of an SD Card containing /boot while the OS itself resides on an SSD, and I'd like to know if there is enough of a performance increase to make it worth while.

I guess it is a case of trying it to see. I have tried running of a USB stick and also off a USB connected HD, and both of these perform better than running of the SD. What improvement a SSD might give I have no idea, and I do not have a spare one to experiment with

Additionally, how much more difficult is it to perform upgrades when the media is split like this?

This is not an issue. You specify in the cmdline.txt file on the SD card boot partition where the root partition is located, and when updating the software always updates the current root partition.

Thanks for the information!

I'll try splitting my installation once my hub arrives tonight and, once I am successful I'll post some benchmark results. Should be interesting...

Any suggestions for benchmarking? (Other than hdparm)

you wont get any speed up via going to an SSD,
your limiting factor is the USB speed.

I have 1 RPi on a 2.5" HD and one on a 1.8" SSD both perform just as well but the 1.8" version is much smaller in all and has a lower power consumption.

both are faster [or at least feel faster from a use point of view - i.e. more responsive] than just an SDcard version - this is because of the disk scheduler to the SD card.

YMMV

I did a few more tests with respect to this and had a few interesting findings:
- my 7 port hub is indeed 2 staggered 4 port bubs.
- if i connect my mass torag to the first level hub, I get good performance and no USB reset messages in dmesg.
- if i connect mass storage to the second level hub, I get bad performance with USB reset messages.

Here's some logs:

USB debug.zip

I hope this helps debugging the USB issue some more.

Regards
Aydan

In deed. You just saved my day. I had the occasinal resets which caused the song played, to start over again. Not a big problem on mp3 files, but I could hardly play a full flac file before it happened.

I moved the HDD to another port on the hub, and have no resets after that.

I did a few more tests with respect to this and had a few interesting findings:
- my 7 port hub is indeed 2 staggered 4 port bubs.
- if i connect my mass torag to the first level hub, I get good performance and no USB reset messages in dmesg.
- if i connect mass storage to the second level hub, I get bad performance with USB reset messages.

Here's some logs:

USB debug.zip

I hope this helps debugging the USB issue some more.

Regards
Aydan

In deed. You just saved my day. I had the occasinal resets which caused the song played, to start over again. Not a big problem on mp3 files, but I could hardly play a full flac file before it happened.

I moved the HDD to another port on the hub, and have no resets after that.

My 7 port hub is also apparently a 3 port + 4 port hub linked inside. The last three ports gives good performance but USB keeps dropping out when anything is connected to the first 4 ports.

Anyone know of a 7 port hub that is really one single hub with equal performance on all ports?

Anything based on a Terminus FE2.1 hub controller is a fair bet - it's a proper multiple-TT 7-port hub supporting most of the bells and whistles.

I lucked out on eBay about 2 years ago and bought 2 of these for super cheap:

http://www.ebay.co.uk/itm/7-Port-USB-2- ... 53f0a94038

But with 2 caveats: it needed modifying for use on the Pi because it back-powered the upstream USB port and it needed the AC adapter thrown in the bin because it was utterly terrible.

Edit: the reason your drive breaks when plugged into the "downstream" hub may be due to a small quirk of the USB spec - there is a SYNC field at the start of every packet. Hubs are allowed to nibble on the first few bits of this field and not pass them on to downstream devices (i.e. gives them time to decide to not propagate packets to devices that are suspended) but a consequence of this is that multiple hubs in series will nibble quite a few bits off the 32 that SYNC in USB2.0 mandates should be transmitted.

In theory a device should be able to work with only 14 sync bits remaining - each hub is allowed up to 4 bits of SYNC nibbling but if you have a crummy nearly-compliant hub coupled with a rather lazy device then it's possible the device will miss packets as it misses the SYNC field.

What does a lsusb -v give with just your hub plugged in?

Hi guys,
I'm rather new in RPI world and moreover in Linux world... but I read a lot before writing this post.

I have a RPI model B with 512MB, distro Raspian, a 10 ports USB Hub with Western Digital "MY PASSPORT" HDD (320GB) EXT3 formatted.
The main used modules are Samba, Transmission and Webmin... the usage is NAS like.
Since yesterday I had a lot of kernel panic problems during Torrent downloads, and I solved it non only updating/upgrading via apt-get, but also upgrading the firmware via RPI-update.

Code: Select all

uname -a
Linux raspberrypi 3.6.7+ #273 PREEMPT Mon Nov 19 19:36:47 GMT 2012 armv6l GNU/Linux

My attention has been the focused on another issue: the slowness of my HDD. In fact:
- test on the SSD:

Code: Select all

sudo hdparm -tT /dev/root
/dev/root:
 Timing cached reads:   286 MB in  2.01 seconds = 142.32 MB/sec
 Timing buffered disk reads:  52 MB in  3.00 seconds =  17.32 MB/sec

- test on the HDD:

Code: Select all

sudo hdparm -tT /dev/sda1
/dev/sda1:
 Timing cached reads:     2 MB in  2.25 seconds = 911.98 kB/sec
 Timing buffered disk reads:   4 MB in  4.27 seconds = 958.48 kB/sec

My first answer was: why the cache is only 2 MB? How can I change it?
I tried the test on any of the 10 USB Ports, with the same results.
So I remembered that in cmdline.txt (under /boot/ dir) I added the command:

Code: Select all

dwc_otg.speed=1

and it means that I RPI was using it as USB 1.1. I sincerely added it because I saw too many errors in kernel.log (under /var/log/ dir) (see also http://raspberrypi.stackexchange.com/questions/1886/what-kernel-parameters-are-available-for-fixing-usb-problems).
Actually with the new firmware and WITHOUT dwc_otg.speed=1 my speed is about 2,5Mb/s for real, and:

Code: Select all

sudo hdparm -tT /dev/sda1
/dev/sda1:
 Timing cached reads:   278 MB in  2.01 seconds = 138.26 MB/sec
 Timing buffered disk reads:   62 MB in  3.09 seconds =  20.09 MB/sec

a great increasing considering that I changed only 1 parameter. A great result but I think we can obtain more that that from the red fruit.

Now my question is: which is the best combination of parameters in config.txt and cmdline.txt (or other configuration files like in samba)?
Maybe it can be useful for all.
Thanks

Are you sure you have upgraded? Mine is:
Linux raspberrypi 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux

Are you sure you have upgraded? Mine is:
Linux raspberrypi 3.6.11+ #371 PREEMPT Thu Feb 7 16:31:35 GMT 2013 armv6l GNU/Linux

Yes, you're right... minor differences.

EDIT:
I've done the last update... now:

Code: Select all

uname -a
Linux raspberrypi 3.6.11+ #403 PREEMPT Tue Apr 2 22:48:13 BST 2013 armv6l GNU/Linux

anyway the speed is always the same (about 2,5 Mb/s in a file transfer).

Code: Select all

 sudo hdparm -tT /dev/sda1
/dev/sda1:
 Timing cached reads:   314 MB in  2.01 seconds = 156.57 MB/sec
 Timing buffered disk reads:  78 MB in  3.06 seconds =  25.47 MB/sec

I had about 1.5MB/s with an external ntfs hd with copying over ssh, and changed the fs to ext4. Now, unexpectedly, even worse: 350KB/s.

My kernel: Linux raspbmc 3.6.11+ #408 PREEMPT Wed Apr 10 20:33:39 BST 2013 armv6l GNU/Linux

I't not the network connection, that is about 78MBit, tested with iperf.

What could help?

Are you using a 7 port USB hub?