# [HLP!] USB 2.0 HDD, hdparm and DMA

## SilveRo

Hi!!

I have a 200 GB usb 2.0 hard drive, a Seagate 7200 rpm, and I have noticed it's performance is not optimal. I have it attached on a Centrino laptop, with only one reiserfs partition.

This the dmesg output when I connect it and turn it on:

```
usb 1-1: new high speed USB device using address 11

scsi6 : SCSI emulation for USB Mass Storage devices

  Vendor: Revoltec  Model: USB/IDE Bridge (  Rev: 0103

  Type:   Direct-Access                      ANSI SCSI revision: 02

SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)

sda: assuming Write Enabled

sda: assuming drive cache: write through

 /dev/scsi/host6/bus0/target0/lun0: p1

Attached scsi removable disk sda at scsi6, channel 0, id 0, lun 0

Attached scsi generic sg0 at scsi6, channel 0, id 0, lun 0,  type 0

USB Mass Storage device found at 11

```

And this is what hdparm says:

```
bash-2.05b# hdparm /dev/sda

/dev/sda:

 HDIO_GET_MULTCOUNT failed: Invalid argument

 readonly     =  0 (off)

 readahead    = 256 (on)

 geometry     = 24321/255/63, sectors = 200049647616, start = 0

```

This is what happens when I try to set the DMA mode:

```
bash-2.05b# hdparm -d1 /dev/sda                                                                                            

/dev/sda:

 setting using_dma to 1 (on)

 HDIO_SET_DMA failed: Invalid argument

```

I guess the "HDIO_GET_MULTCOUNT failed: Invalid argument" is causing all the problems.... does anyone some good advice, or knows how to solve this issue? I have no problem what so ever with DMA on my main hard disk.

THX  =)

[EDIT] BTW, I don't have SCSI emulation in the kernel. Can this be the problem? I have no problem writing and reading from the hard disk....

[EDIT] nope, even with scsi emulation, the problem doesn't go away....

[EDIT] Here are some performance examples... as you can see, my laptop's hard disk performs better than my USB 2.0 7200 rpm hard disk    :Sad: 

```
bash-2.05b# hdparm -tT /dev/sda

/dev/sda:

 Timing cached reads:   1524 MB in  2.00 seconds = 761.73 MB/sec

 Timing buffered disk reads:   58 MB in  3.04 seconds =  19.09 MB/sec

bash-2.05b# hdparm -tT /dev/hda

/dev/hda:

 Timing cached reads:   1712 MB in  2.00 seconds = 855.27 MB/sec

 Timing buffered disk reads:   70 MB in  3.04 seconds =  23.01 MB/sec

```

----------

## deadmoo

as far as i know hdparm is only for devices that run through ide in the kernel and usb storage devices are implemented through a scsi driver. so i don't think hdparm can be used on usb devices.

----------

## SilveRo

 *deadmoo wrote:*   

> as far as i know hdparm is only for devices that run through ide in the kernel and usb storage devices are implemented through a scsi driver. so i don't think hdparm can be used on usb devices.

 

I see.... how can I improve the performance of my USB drive, then? The actual transfer speed of the hard disk is limited by the USB 2.0 connection, so I hope to obtain transfer rates close to 60MB/sec....

----------

## deadmoo

first i would make sure that it is in fact utilizing the 2.0 and not running at 1.1 speeds. if it isn't utilizing the 2.0 then perhaps the usb 2.0 driver (ehci) isn't loaded and only the usb 1.1 driver is (ohci or uhci).

----------

## SilveRo

 *deadmoo wrote:*   

> first i would make sure that it is in fact utilizing the 2.0 and not running at 1.1 speeds. if it isn't utilizing the 2.0 then perhaps the usb 2.0 driver (ehci) isn't loaded and only the usb 1.1 driver is (ohci or uhci).

 

I have the USB 2.0 support built into the kernel, and the output of the dmesg says "High Speed" (USB 1.1 is "Full Speed"). Besides, USB 1.1 supports speeds up to 1.5 MB/sec, and I go beyond that (check out the output of the hdparm -Tt I posted). 

I wonder if there is any way to use DMA when the hard disk is connected via USB 2.0 (with SCSI emulation).

Thx for the advice so far, I appretiate it.    :Very Happy: 

----------

## pax82

hdparm won't help you. 

I have problems with my USB CDROM on kernel 2.6.8.1 (I know that you have kernel : 2.6.7, becouse in earliel there was no Vendor: Revoltec  Model: USB/IDE Bridge dev. That patch (revoltec) is bad and I have write patch that remove revoltec. Try to apply that and check if it helps.

-----------[ CUT HERE ]-----------

--- linux-2.6.8.1/drivers/usb/storage/unusual_devs.h	2004-08-14 12:55:59.000000000 +0200

+++ linux-2.6.8.1-px/drivers/usb/storage/unusual_devs.h	2004-09-30 23:13:42.313796376 +0200

@@ -73,16 +73,6 @@

 		US_SC_8070, US_PR_SCM_ATAPI, init_8200e, 0), 

 #endif

-/* <torsten.scherer@uni-bielefeld.de>: I don't know the name of the bridge

- * manufacturer, but I've got an external USB drive by the Revoltec company

- * that needs this. otherwise the drive is recognized as /dev/sda, but any

- * access to it blocks indefinitely.

- */

-UNUSUAL_DEV(  0x0402, 0x5621, 0x0103, 0x0103,

-		"Revoltec",

-		"USB/IDE Bridge (ATA/ATAPI)",

-		US_SC_DEVICE, US_PR_DEVICE, NULL, US_FL_FIX_INQUIRY),

-

 /* Deduced by Jonathan Woithe <jwoithe@physics.adelaide.edu.au>

  * Entry needed for flags: US_FL_FIX_INQUIRY because initial inquiry message

  * always fails and confuses drive.

-----------[ CUT HERE ]-----------

----------

## SilveRo

 *pax82 wrote:*   

> hdparm won't help you. 
> 
> I have problems with my USB CDROM on kernel 2.6.8.1 (I know that you have kernel : 2.6.7, becouse in earliel there was no Vendor: Revoltec  Model: USB/IDE Bridge dev. That patch (revoltec) is bad and I have write patch that remove revoltec. Try to apply that and check if it helps.
> 
> -----------[ CUT HERE ]-----------
> ...

 

Thanks for the advice!!! I am running the gentoo-dev-sources 2.6.8-r3 (I will upgrade to the r8 soon). As soon as I have a chance to reboot, I will try your patch and let you know!!!

----------

## SilveRo

I removed the Revoltec patch, editing the kernel by hand, and I haven't solved the problem. (Thx anyhow for the advice!!!). This is how the hard disk shows up in dmesg after editing the kernel:

```
usb 1-1: new high speed USB device using address 3

Initializing USB Mass Storage driver...

scsi0 : SCSI emulation for USB Mass Storage devices

Vendor: USB 2.0   Model: Storage Device    Rev: 0100

   Type:   Direct-Access                      ANSI SCSI revision: 02

   SCSI device sda: 390721968 512-byte hdwr sectors (200050 MB)

   sda: assuming drive cache: write through

   /dev/scsi/host0/bus0/target0/lun0: p1

   Attached scsi disk sda at scsi0, channel 0, id 0, lun 0

   Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0,  type 0

   USB Mass Storage device found at 3

   usbcore: registered new driver usb-storage

   USB Mass Storage support registered.

```

But I still have the same problem:

```
bash-2.05b# hdparm /dev/sda

/dev/sda:

 HDIO_GET_MULTCOUNT failed: Invalid argument

 readonly     =  0 (off)

 readahead    = 256 (on)

 geometry     = 24321/255/63, sectors = 200049647616, start = 0

```

Does anyone else have any idea why? 

Once again: I can't activate DMA mode, and this error seems to have to do with the problem.

----------

## SilveRo

I just now tried with a Knoppix cd; I get the same hdparm output, but without the "HDIO_GET_MULTCOUNT failed: Invalid argument" error. When I try to set the DMA mode, it says that I can't do this to SCSI devices with hdparm. Maybe there is no way to use hdparm to make my hard disk work in DMA mode.... the problem is that the performance is not optimal....

Isn't there any way (with DMA, or anything else) to make a USB 2.0 IDE hard drive work decently, even though it works through SCSI emulation? Correct me if I'm wrong, but the only way to access it is having Linux see it as a SCSI device....

----------

## teilo

 *SilveRo wrote:*   

> I just now tried with a Knoppix cd; I get the same hdparm output, but without the "HDIO_GET_MULTCOUNT failed: Invalid argument" error. When I try to set the DMA mode, it says that I can't do this to SCSI devices with hdparm. Maybe there is no way to use hdparm to make my hard disk work in DMA mode.... the problem is that the performance is not optimal....
> 
> Isn't there any way (with DMA, or anything else) to make a USB 2.0 IDE hard drive work decently, even though it works through SCSI emulation? Correct me if I'm wrong, but the only way to access it is having Linux see it as a SCSI device....

 

DMA support for an IDE on USB harddrive is entirely in the hands of the IDE-to-USB hardware bridge inside your external harddrive. The kernel has no way of accessing or changing that information for a generic USB Mass Storage device.

SCSI emulation does not add noticable overhead to a storage device's performance. Compare the performance of an IDE CDROM drive in native versus generic SCSI emulation mode. Hardly any difference. Native SATA drives also use the SCSI kernel layer, and they are exteremly fast. If you are experiencing undue slowness, it is most certainly caused by some problem in the drive itself, or your USB setup.

Is this a Seagate branded external HD, or did you puchase an external housing, and put in a Seagate drive? I have a Seagate 160 which I put into a USB housing. I will test it and report the results, so that you will at least have something to which you can compare your performance.

----------

## pilla

What are the options that you are using in your /etc/fstab for that partition? Are you using noatime?

----------

## SilveRo

 *pilla wrote:*   

> What are the options that you are using in your /etc/fstab for that partition? Are you using noatime?

 

Here it is:

```
/dev/sda1               /mnt/usb2_HDD   reiserfs        noatime,user,noauto,exec        0 0
```

Is this relevant? When I do "hdparm -tT /dev/sda" I don't have sda1 mounted....

----------

## SilveRo

 *teilo wrote:*   

>  *SilveRo wrote:*   I just now tried with a Knoppix cd; I get the same hdparm output, but without the "HDIO_GET_MULTCOUNT failed: Invalid argument" error. When I try to set the DMA mode, it says that I can't do this to SCSI devices with hdparm. Maybe there is no way to use hdparm to make my hard disk work in DMA mode.... the problem is that the performance is not optimal....
> 
> Isn't there any way (with DMA, or anything else) to make a USB 2.0 IDE hard drive work decently, even though it works through SCSI emulation? Correct me if I'm wrong, but the only way to access it is having Linux see it as a SCSI device.... 
> 
> DMA support for an IDE on USB harddrive is entirely in the hands of the IDE-to-USB hardware bridge inside your external harddrive. The kernel has no way of accessing or changing that information for a generic USB Mass Storage device.
> ...

 

It's a Western Digital hard drive, in an external housing, not of the same brand. Actually, I bought both of them, already put together, on EBAY.

----------

## pilla

 *SilveRo wrote:*   

>  *pilla wrote:*   What are the options that you are using in your /etc/fstab for that partition? Are you using noatime? 
> 
> Here it is:
> 
> ```
> ...

 

hdparm does not work but on /dev/hd* devices.

man mount:

 *Quote:*   

> 
> 
> noatime
> 
>                      Do  not  update inode access times on this file system (e.g,
> ...

 

It may reduce the load on that disk.

----------

## SilveRo

 *pilla wrote:*   

>  *SilveRo wrote:*    *pilla wrote:*   What are the options that you are using in your /etc/fstab for that partition? Are you using noatime? 
> 
> Here it is:
> 
> ```
> ...

 

I see. Strangely, it did give me some results (see my previous posts). Running it on sda1 gives me the same data....

----------

## pilla

You can access the same settings in /proc. 

However, don't trust hdparm as a benchmark (and even less when you run it only once for each disk).

----------

## SilveRo

 *pilla wrote:*   

> You can access the same settings in /proc. 
> 
> However, don't trust hdparm as a benchmark (and even less when you run it only once for each disk).

 

Here is what I have in /proc, with some 'cat's (can't find anything else):

```
bash-2.05b$ ls /proc/scsi/

device_info  scsi  sg/  usb-storage/

bash-2.05b$ cat /proc/scsi/scsi 

Attached devices:

Host: scsi0 Channel: 00 Id: 00 Lun: 00

  Vendor: Revoltec Model: USB/IDE Bridge ( Rev: 0103

  Type:   Direct-Access                    ANSI SCSI revision: 02

bash-2.05b$ ls /proc/scsi/sg/  

allow_dio  debug  def_reserved_size  device_hdr  device_strs  devices  version

bash-2.05b$ cat /proc/scsi/usb-storage/0 

   Host scsi0: usb-storage

       Vendor: Revoltec

      Product: USB 2.0 Storage Device

Serial Number: 00042222200000124530

     Protocol: Transparent SCSI

    Transport: Bulk

       Quirks: FIX_INQUIRY

bash-2.05b$ cat /proc/scsi/sg/allow_dio 

0

```

I wonder if this allow_dio is the issue.... can DIO stand for "Direct Input Output", something like DMA?   :Razz:   I would try setting it to 1, but the thought of doing it kind'a scares me....

----------

## SilveRo

 *SilveRo wrote:*   

> I wonder if this allow_dio is the issue.... can DIO stand for "Direct Input Output", something like DMA?    I would try setting it to 1, but the thought of doing it kind'a scares me....

 

Well, google answered my questions:

```
9.1. Direct IO

Direct IO uses the kiobuf mechanism [see the Linux Device Drivers book] to manipulate memory allocated within the user space so that a lower level (adapter) driver can DMA directly to or from that user space memory. Since the user can give a different data buffer to each SCSI command passed through the sg interface then the kiobuf mechanism needs to setup its structures (and undo that setup) for each SCSI command. [17] Direct IO is available as an option in sg 3.1.18 (before that the sg driver needed to be recompiled with an altered define). Direct IO support is designed in such a way that if it is requested and cannot be performed then the command will still be performed using indirect IO. If direct IO is requested and has been performed then the SG_INFO_DIRECT_IO bit will be set in the 'info' member of the sg_io_hdr_t control structure after the request has been completed. Direct IO is not supported on ISA SCSI adapters since they only can address a 24 bit address space.

One limit on direct IO is that sg_io_hdr_t::iovec_count==0. So the user cannot (currently) use application level scatter gather and direct IO on the same request.

For direct IO to be worthwhile, a reasonable amount of data should be requested for data transfer. For transfers less than 8 KByte it is probably not worth the trouble. On the other hand "locking down" a multiple 512 KB blocks of data for direct IO could adversely impact overall system performance. Remember that for the duration of a direct IO request, the data transfer buffer is mapped to a fixed memory location and locked in such a way that it won't be swapped out. This can "cramp the style" of the kernel if it is overdone.

Prior to sg 3.1.18 the direct IO code was commented out with the "SG_ALLOW_DIO" define. In sg 3.1.18 (available for lk 2.4.2 and later) the direct IO code is active but is defaulted off by a run time value. This value can be accessed via the "proc" file system at /proc/scsi/sg/allow_dio . Direct IO is enabled when a user with root permissions writes "1" to that file: echo 1 > /proc/scsi/sg/allow_dio . If SG_FLAG_DIRECT_IO is set in sg_io_hdr::flags but /proc/scsi/sg/allow_dio holds "0" then indirect IO will be performed (and this is indicated by ((sg_io_hdr::info & SG_INFO_DIRECT_IO_MASK) == SG_INFO_INDIRECT_IO) after the request is completed).
```

I just can't figure out if this would help, and if it is safe.... I am quite clueless about SCSI....

----------

## mike4148

AFAIK, this isn't some kind of configuration problem you can easily solve. My external 120gb 7200 RPM Maxtor USB 2.0 drive shows similar performance numbers. Regardless, you can't mess with its settings using hdparm. I would recommend searching for hdparm scores from external drives of various types; don't be surprised if USB drives tend to top out in the 20-30 meg/sec. area.

----------

## SilveRo

 *mike4148 wrote:*   

> AFAIK, this isn't some kind of configuration problem you can easily solve. My external 120gb 7200 RPM Maxtor USB 2.0 drive shows similar performance numbers. Regardless, you can't mess with its settings using hdparm. I would recommend searching for hdparm scores from external drives of various types; don't be surprised if USB drives tend to top out in the 20-30 meg/sec. area.

 

Man this sucks.... I just hope it's not just a Linux issue.... I wouldn't feel so bad if it had the same problem under Windows   :Smile: 

----------

## SilveRo

Yep, I googled around, and other people have raised this issue.... It probably has a lot to do with the controller.... I haven't found out if firewire offers better performance. Some people claim that on Windows it is faster; after all, this could be considered positive, because it gives us hope that it will improve with time in Linux....

----------

## pax82

 *SilveRo wrote:*   

> I removed the Revoltec patch, editing the kernel by hand, and I haven't solved the problem. (Thx anyhow for the advice!!!). This is how the hard disk shows up in dmesg after editing the kernel:
> 
> But I still have the same problem:
> 
> ```
> ...

 

don't try to use DMA on that disk, juz check hdparm -t /dev/sda.

My friend hve USB/IDE bridge and disk in it, and he have no options in hdparm like dma or sth. lik that, in hdparm -t /dev/sda he has 26 Mb/s. If you wille have about 26mb/s it;s good.

----------

## SilveRo

 *pax82 wrote:*   

>  *SilveRo wrote:*   I removed the Revoltec patch, editing the kernel by hand, and I haven't solved the problem. (Thx anyhow for the advice!!!). This is how the hard disk shows up in dmesg after editing the kernel:
> 
> But I still have the same problem:
> 
> ```
> ...

 

I have about 19, and it didn't get better removing Revoltec from the kernel.... I guess I will settle for what I have   :Smile: 

----------

