Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On 10/09/2014 07:07 PM, Mark Knibbs wrote: [For removable media, it's a good idea to disable polling for medium changes before running a test. Depending on kernel & distribution that could be achieved by doing udisks --inhibit-all-polling and/or for example echo -1 >/sys/block/sdb/events_poll_msecs before running the test.] I still can't reproduce this issue. >>> Disable polling root@allen-ivb:/home/allen# uname -a Linux allen-ivb 3.17.0+ #1 SMP Thu Oct 9 16:19:28 CST 2014 x86_64 x86_64 x86_64 GNU/Linux root@allen-ivb:/home/allen# udisks --inhibit-all-polling Inhibiting polling on all devices. Press Ctrl+C to exit. >>> Change to another terminal >>> Connected to USB 2.0 port via USB 1.1 hub: root@allen-ivb:/home/allen# lsusb -t /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M |__ Port 5: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 6: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 6: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M |__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/3p, 12M |__ Port 1: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 1: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 3: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 12M root@allen-ivb:/home/allen# ddpt if=/dev/sg2 bs=512 bpt=240 count=65536 verbose=2 >> Input file type: pass-through [pt] device open /dev/sg2 with flags=0x802 inquiry cdb: 12 00 00 00 24 00 /dev/sg2: ASMT 2105 0 [pdt=0] >> Output file type: null device read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 /dev/sg2 [pt]: blocks=6250 [0x3b9aca0], _bs=512, 32.00 GB skip=0 (blocks on input), seek=0 (blocks on output) ibs=512 bytes, obs=512 bytes, OBPC=0 initial count=65536 (blocks of input), blocks_per_transfer=240 Output file not specified so no copy, just reading input 65536+0 records in 0+0 records out time to read data: 30.097182 secs at 1.11 MB/sec >>> Connected to USB 3.0 port via USB 1.1 hub: root@allen-ivb:/home/allen# lsusb -t /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M |__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/3p, 12M |__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 1: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 3: Dev 4, If 0, Class=Mass Storage, Driver=usb-storage, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M |__ Port 5: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 6: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 6: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M root@allen-ivb:/home/allen# ddpt if=/dev/sg2 bs=512 bpt=240 count=65536 verbose=2 >> Input file type: pass-through [pt] device open /dev/sg2 with flags=0x802 inquiry cdb: 12 00 00 00 24 00 /dev/sg2: ASMT 2105 0 [pdt=0] >> Output file type: null device read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 /dev/sg2 [pt]: blocks=6250 [0x3b9aca0], _bs=512, 32.00 GB skip=0 (blocks on input), seek=0 (blocks on output) ibs=512 bytes, obs=512 bytes, OBPC=0 initial count=65536 (blocks of input), blocks_per_transfer=240 Output file not specified so no copy, just reading input 65536+0 records in 0+0 records out time to read data: 27.900788 secs at 1.20 MB/sec Thanks, -baolu -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On Thu, 9 Oct 2014, Mark Knibbs wrote: > I finally finished doing git bisect between 2.6.33 and 2.6.34. Sadly I'm > not really any the wiser, since the result looks pretty bogus. > > The supposedly-bad commit was: > 002345925e6c45861f60db6f4fc6236713fd8847 > syslog: distinguish between /proc/kmsg and syscalls > > There doesn't seem to be anything in that which could cause the problem; > perhaps something went wrong with the bisection? That commit doesn't > cleanly revert with later kernel versions. Git bisect isn't always reliable. You need to validate the final result by testing both the first bad commit and its parent (the last good commit). If their behaviors are different then you can conclude that the bad commit caused the difference. Sometimes the nature of the cause isn't readily apparent. For example, a change in one part of the kernel may result in a subtle timing difference that has an unexpectedly large effect on another part of the kernel. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
Hi, On Thu, 09 Oct 2014 16:45:39 +0800 Lu Baolu wrote: > I got a different result with my machine. Below is the details. > ... > >>> Connected to USB 2.0 port via USB 1.1 hub: > ... > allen@allen-ivb:~$ sudo ddpt if=/dev/sg2 bs=512 bpt=240 count=65536 > verbose=2 > ... > time to read data: 30.037081 secs at 1.12 MB/sec > > >>> Connected to USB 3.0 port via USB 1.1 hub: > ... > allen@allen-ivb:~$ sudo ddpt if=/dev/sg2 bs=512 bpt=240 count=65536 > verbose=2 > ... > time to read data: 27.816240 secs at 1.21 MB/sec That result is close to what I see with a "good" kernel (e.g. 2.6.33.20); the USB3 port case was about 8% faster for you. It's only about 0.05% faster on my system. [For removable media, it's a good idea to disable polling for medium changes before running a test. Depending on kernel & distribution that could be achieved by doing udisks --inhibit-all-polling and/or for example echo -1 >/sys/block/sdb/events_poll_msecs before running the test.] Mark -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On Mon, 29 Sep 2014 09:28:37 -0400 (EDT) Alan Stern wrote: > On Sun, 28 Sep 2014, Mark Knibbs wrote: > > > > There's no telling the reason for this difference. It's got to be a > > > hardware issue, though, not a software problem. Maybe your xHCI > > > controller just isn't optimized for carrying out full-speed transfers. > > > > That's a possibility, but the improvement between my initial test with > > kernel 3.14 and 3.16.2 (0.63MB/sec -> 0.75MB/sec) was obviously down to > > software. > > Since you reliably observe a difference in speed between these kernels, > you are in an ideal situation to use bisection. That ought to pinpoint > the code changes responsible for the speed difference. I finally finished doing git bisect between 2.6.33 and 2.6.34. Sadly I'm not really any the wiser, since the result looks pretty bogus. The supposedly-bad commit was: 002345925e6c45861f60db6f4fc6236713fd8847 syslog: distinguish between /proc/kmsg and syscalls There doesn't seem to be anything in that which could cause the problem; perhaps something went wrong with the bisection? That commit doesn't cleanly revert with later kernel versions. At this point I'm pretty much stumped. Each kernel version seemed consistently "good" or "bad". I tested 2.6.33.20 five times, rebooting and/or power-cycling between tests, and in every case the USB3 rate was 100.05% or 100.06% times the USB2 rate. All "good" kernels in the bisection were like that. Some "bad" kernels did show widely varying results, but all were noticeably lower than the good case. For example, the results I got for testing 2.6.34.7 five times (USB3 speed as percentage of USB2 speed): 98.72%, 90.66%, 90.90%, 82.18%, 71.28% And testing 2.6.34.4: 65.69%, 65.60%, 71.77% In case it's of any use, here's the output of git bisect log I got. git bisect start # good: [60b341b778cc2929df16c0a504c91621b3c6a4ad] Linux 2.6.33 git bisect good 60b341b778cc2929df16c0a504c91621b3c6a4ad # bad: [e40152ee1e1c7a63f491863215e3faa37a86] Linus 2.6.34 git bisect bad e40152ee1e1c7a63f491863215e3faa37a86 # bad: [64ba9926759792cf7b95f823402e2781edd1b5d4] Merge branch 'for-linus' of git://git.open-osd.org/linux-open-osd git bisect bad 64ba9926759792cf7b95f823402e2781edd1b5d4 # good: [d3ae8562d43fe2b97d605dd67dc67bf8fa9b956a] usb: host: ehci: fix missing kfree in remove path also git bisect good d3ae8562d43fe2b97d605dd67dc67bf8fa9b956a # good: [2ac2ed5f2dfc97ae9ed9f446ad6e064fa821ef6d] gigaset: small documentation improvement git bisect good 2ac2ed5f2dfc97ae9ed9f446ad6e064fa821ef6d # bad: [c1dcb4bb1e3e16e9baee578d9bb040e5fba1063e] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6 git bisect bad c1dcb4bb1e3e16e9baee578d9bb040e5fba1063e # good: [5057bfaff82e12f01a2ffd58f55535cbd7c5c3a2] Merge branch 'omap-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6 git bisect good 5057bfaff82e12f01a2ffd58f55535cbd7c5c3a2 # bad: [3ff1562ea48cddaa5ac1adcb8892227389a4c96c] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/roland/infiniband git bisect bad 3ff1562ea48cddaa5ac1adcb8892227389a4c96c # bad: [832d30ca72c0a59058e66e097f5ea11f99640819] Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6 git bisect bad 832d30ca72c0a59058e66e097f5ea11f99640819 # good: [d2e82add832f9c95376d004d565c5e164c99b9ec] OMAP: DSS2: OMAPFB: install omapfb.h git bisect good d2e82add832f9c95376d004d565c5e164c99b9ec # bad: [d78ca3cd733d8a2c3dcd88471beb1a15d973eed8] syslog: use defined constants instead of raw numbers git bisect bad d78ca3cd733d8a2c3dcd88471beb1a15d973eed8 # good: [e41035a996356c257183e53a70abfb46fa84908b] TOMOYO: Remove memory pool for string data. git bisect good e41035a996356c257183e53a70abfb46fa84908b Mark -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
Hi Mark, I got a different result with my machine. Below is the details. >>> Kernel version allen@allen-ivb:~$ uname -a Linux allen-ivb 3.17.0+ #1 SMP Thu Oct 9 16:19:28 CST 2014 x86_64 x86_64 x86_64 GNU/Linux >>> Host controler information allen@allen-ivb:~$ lspci | grep USB 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) >>> Connected to USB 2.0 port via USB 1.1 hub: allen@allen-ivb:~$ lsusb -t /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M |__ Port 5: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 6: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 6: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M |__ Port 4: Dev 3, If 0, Class=Hub, Driver=hub/3p, 12M |__ Port 1: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 1: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 3: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 12M allen@allen-ivb:~$ sudo ddpt if=/dev/sg2 bs=512 bpt=240 count=65536 verbose=2 [sudo] password for allen: >> Input file type: pass-through [pt] device open /dev/sg2 with flags=0x802 inquiry cdb: 12 00 00 00 24 00 /dev/sg2: ASMT 2105 0 [pdt=0] >> Output file type: null device read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 /dev/sg2 [pt]: blocks=6250 [0x3b9aca0], _bs=512, 32.00 GB skip=0 (blocks on input), seek=0 (blocks on output) ibs=512 bytes, obs=512 bytes, OBPC=0 initial count=65536 (blocks of input), blocks_per_transfer=240 Output file not specified so no copy, just reading input 65536+0 records in 0+0 records out time to read data: 30.037081 secs at 1.12 MB/sec >>> Connected to USB 3.0 port via USB 1.1 hub: allen@allen-ivb:~$ lsusb -t /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M |__ Port 3: Dev 2, If 0, Class=Hub, Driver=hub/3p, 12M |__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 1: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 3: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 12M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M |__ Port 5: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 6: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M |__ Port 6: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M allen@allen-ivb:~$ sudo ddpt if=/dev/sg2 bs=512 bpt=240 count=65536 verbose=2 >> Input file type: pass-through [pt] device open /dev/sg2 with flags=0x802 inquiry cdb: 12 00 00 00 24 00 /dev/sg2: ASMT 2105 0 [pdt=0] >> Output file type: null device read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 /dev/sg2 [pt]: blocks=6250 [0x3b9aca0], _bs=512, 32.00 GB skip=0 (blocks on input), seek=0 (blocks on output) ibs=512 bytes, obs=512 bytes, OBPC=0 initial count=65536 (blocks of input), blocks_per_transfer=240 Output file not specified so no copy, just reading input 65536+0 records in 0+0 records out time to read data: 27.816240 secs at 1.21 MB/sec Thanks, -baolu On 09/30/2014 05:19 PM, Mark Knibbs wrote: On Tue, 30 Sep 2014 14:10:28 +0800 "Lu, Baolu" wrote: On 9/30/2014 5:03 AM, Mark Knibbs wrote: Great. I hope someone else is motivated to reproduce the issue. It will take a long time for me to bisect due to my slow computer. Hi Mark, I tried to reproduce this issue. I connected a USB key under a full-speed hub. Just to confirm, I do see the slowdown with a USB 2.0 drive connected to USB 1.1 hub connected to USB 3.0 port. My results (kernel 3.17-rc6): Connected to USB 3.0 port via USB 1.1 hub: # ddpt if=/dev/sg6 bs=512 bpt=240 count=65536 verbose=2 >> Input file type: pass-through [pt] device open /dev/sg6 with flags=0x802 inquiry cdb: 12 00 00 00 24 00 /dev/sg6: Freecom DataBar USB2.02.00 [pdt=0] >> Output file type: null device read capacity (10) cdb: 25 00
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On Tue, 30 Sep 2014 14:10:28 +0800 "Lu, Baolu" wrote: > On 9/30/2014 5:03 AM, Mark Knibbs wrote: > > Great. I hope someone else is motivated to reproduce the issue. It will > > take a long time for me to bisect due to my slow computer. > Hi Mark, > > I tried to reproduce this issue. I connected a USB key under a > full-speed hub. Just to confirm, I do see the slowdown with a USB 2.0 drive connected to USB 1.1 hub connected to USB 3.0 port. My results (kernel 3.17-rc6): Connected to USB 3.0 port via USB 1.1 hub: # ddpt if=/dev/sg6 bs=512 bpt=240 count=65536 verbose=2 >> Input file type: pass-through [pt] device open /dev/sg6 with flags=0x802 inquiry cdb: 12 00 00 00 24 00 /dev/sg6: Freecom DataBar USB2.02.00 [pdt=0] >> Output file type: null device read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 /dev/sg6 [readcap]: num_blocks=127908 [0x1f3a4], block_size=512, 65 MB skip=0 (blocks on input), seek=0 (blocks on output) ibs=512 bytes, obs=512 bytes, OBPC=0 initial count=65536 (blocks of input), blocks_per_transfer=240 Output file not specified so no copy, just reading input 65536+0 records in 0+0 records out time to read data: 58.147836 secs at 577.1 KB/sec Connected to USB 2.0 port via USB 1.1 hub: # ddpt if=/dev/sg6 bs=512 bpt=240 count=65536 verbose=2 >> Input file type: pass-through [pt] device open /dev/sg6 with flags=0x802 inquiry cdb: 12 00 00 00 24 00 /dev/sg6: Freecom DataBar USB2.02.00 [pdt=0] >> Output file type: null device read capacity (10) cdb: 25 00 00 00 00 00 00 00 00 00 /dev/sg6 [readcap]: num_blocks=127908 [0x1f3a4], block_size=512, 65 MB skip=0 (blocks on input), seek=0 (blocks on output) ibs=512 bytes, obs=512 bytes, OBPC=0 initial count=65536 (blocks of input), blocks_per_transfer=240 Output file not specified so no copy, just reading input 65536+0 records in 0+0 records out time to read data: 39.146843 secs at 857.1 KB/sec Mark -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On Tue, 30 Sep 2014 14:10:28 +0800 "Lu, Baolu" wrote: > I tried to reproduce this issue. I connected a USB key under a > full-speed hub. > > sg_rbuf returns error which I am not familiar with. > > allen@allen-ivb:~$ lsusb -t > [...snip...] > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M > |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M > |__ Port 4: Dev 11, If 0, Class=Hub, Driver=hub/3p, 12M > |__ Port 1: Dev 12, If 0, Class=Human Interface Device, > Driver=usbhid, 12M > |__ Port 1: Dev 12, If 1, Class=Human Interface Device, > Driver=usbhid, 12M > |__ Port 3: Dev 15, If 0, Class=Mass Storage, > Driver=usb-storage, 12M > > allen@allen-ivb:~$ sudo dd if=/dev/zero of=/dev/sdb bs=4k count=1k > 1024+0 records in > 1024+0 records out > 4194304 bytes (4.2 MB) copied, 4.32676 s, 969 kB/s > > allen@allen-ivb:~$ sudo sg_rbuf --buffer=524288 -q -t -v /dev/sg2 > Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 > READ BUFFER descriptor error: SCSI status: Check Condition > Fixed format, current; Sense key: Illegal Request > Additional sense: Invalid command operation code You won't be able to use sg_rbuf. sg_rbuf issues READ BUFFER commands, which most/all USB sticks won't support. Using dd instead should be fine to show the problem. In the USB tree you posted, the hub is connected to a USB 2.0 port and the 969KB/sec dd result looks reasonable. Now try with the USB 1.1 hub connected to a USB 3.0 port. For my testing, I increased the maximum USB transfer size using a command like echo 1024 >/sys/block/sdb/device/max_sectors [By default the kernel limits transfers to 120KB (240 512-byte sectors), presumably because some devices break with larger ones. Changing that shouldn't be necessary to show the problem though.] If you want to bypass the block layer, you could use ddpt instead of dd; see http://sg.danny.cz/sg/ddpt.html ddpt can issue SCSI commands directly, so you could do something like ddpt if=/dev/sdb of=/dev/null bs=512 bpt=240 count=65536 verbose=2 iflag=pt to time reading the first 32MB. Mark -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On 9/30/2014 5:03 AM, Mark Knibbs wrote: Great. I hope someone else is motivated to reproduce the issue. It will take a long time for me to bisect due to my slow computer. Hi Mark, I tried to reproduce this issue. I connected a USB key under a full-speed hub. sg_rbuf returns error which I am not familiar with. allen@allen-ivb:~$ lsusb -t [...snip...] /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M |__ Port 4: Dev 11, If 0, Class=Hub, Driver=hub/3p, 12M |__ Port 1: Dev 12, If 0, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 1: Dev 12, If 1, Class=Human Interface Device, Driver=usbhid, 12M |__ Port 3: Dev 15, If 0, Class=Mass Storage, Driver=usb-storage, 12M allen@allen-ivb:~$ sudo dd if=/dev/zero of=/dev/sdb bs=4k count=1k 1024+0 records in 1024+0 records out 4194304 bytes (4.2 MB) copied, 4.32676 s, 969 kB/s allen@allen-ivb:~$ sudo sg_rbuf --buffer=524288 -q -t -v /dev/sg2 Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 READ BUFFER descriptor error: SCSI status: Check Condition Fixed format, current; Sense key: Illegal Request Additional sense: Invalid command operation code Thanks, -baolu -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On Mon, 29 Sep 2014 09:28:37 -0400 (EDT) Alan Stern wrote: > On Sun, 28 Sep 2014, Mark Knibbs wrote: > > > > There's no telling the reason for this difference. It's got to be a > > > hardware issue, though, not a software problem. Maybe your xHCI > > > controller just isn't optimized for carrying out full-speed transfers. > > > > That's a possibility, but the improvement between my initial test with > > kernel 3.14 and 3.16.2 (0.63MB/sec -> 0.75MB/sec) was obviously down to > > software. > > Since you reliably observe a difference in speed between these kernels, > you are in an ideal situation to use bisection. That ought to pinpoint > the code changes responsible for the speed difference. I'll try to get onto that shortly. It will be very painful on my old laptop though..! > > I re-tested today with kernel 3.17-rc6 (on Lubuntu 12.04.5) and the USB 3.0 > > result is back down to ~0.63MB/sec: > > # sg_rbuf --buffer=524288 -v -t -q /dev/sg5 > > Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 > > READ BUFFER reports: buffer capacity=983040, offset boundary=0 > > time to read data from buffer was 332.637465 secs, 0.63 MB/sec > > Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) > > Again, bisection should help. Not a proper bisection, but today I tested various kernels as available from http://kernel.ubuntu.com/~kernel-ppa/mainline/ Quite interesting! It's not a hardware issue after all, and it's quite an old regression. The USB 2 port rates are very consistent over all kernels. 2.6.32 and 2.6.33 are just as fast in USB 3.0 ports (in fact 0.05% faster) as in USB 2.0 ports. The regression occurred between 2.6.33 and 2.6.34, after which USB 1.1 devices work 40% faster in USB 2 ports than USB 3 ports. There was some improvement between 3.10 and 3.14, but things regressed again between 3.16 and 3.17-rc1. Kernel USB2 time USB3 time USB2 rate USB3 rate USB3%of2 %USB2faster 2.6.32.63.26 242.405270 242.283844 865,142.9 865,576.5 100.05%-0.05% 2.6.33.20242.400737 242.285208 865,159.1 865,571.6 100.05%-0.05% 2.6.34.15242.400247 340.095006 865,160.8 616,637.1 71.27% 40.30% 2.6.36.4 242.400864 339.286585 865,158.6 618,106.4 71.44% 39.97% 3.7.10 243.009366 340.206814 862,992.3 616,434.4 71.43% 40.00% 3.10.55 242.400230 336.598467 865,160.9 623,042.6 72.01% 38.86% 3.14.19 242.401219 287.017822 865,157.4 730,669.6 84.46% 18.41% 3.16.2 242.400229 284.858724 865,160.9 736,207.7 85.09% 17.52% 3.16.3 242.400258 289.192172 865,160.8 725,175.9 83.82% 19.30% 3.17-rc1 242.400248 339.129056 865,160.8 618,393.5 71.48% 39.90% 3.17-rc6 242.400239 339.548579 865,160.9 617,629.4 71.39% 40.08% > > For someone with no actual USB 1.1 drive, could connecting a USB 2.0 drive > > through an old USB 1.1 hub (then to a USB 2.0 or 3.0 port) work for > > testing? USB 1.1 hubs are probably still relatively easy to come by. > > Yes, that would work. Great. I hope someone else is motivated to reproduce the issue. It will take a long time for me to bisect due to my slow computer. Mark -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On Sun, 28 Sep 2014, Mark Knibbs wrote: > > There's no telling the reason for this difference. It's got to be a > > hardware issue, though, not a software problem. Maybe your xHCI > > controller just isn't optimized for carrying out full-speed transfers. > > That's a possibility, but the improvement between my initial test with > kernel 3.14 and 3.16.2 (0.63MB/sec -> 0.75MB/sec) was obviously down to > software. Since you reliably observe a difference in speed between these kernels, you are in an ideal situation to use bisection. That ought to pinpoint the code changes responsible for the speed difference. > So there could be a lack of testing xhci_hcd with old USB 1.1 > devices too. Someone else would really need to reproduce these results > though; the different kernels could have been built with different options > which may have affected the results. But in all cases, via a USB 3.0 port > the transfer is significantly slower. > > Does the kernel driver have to poll the USB port? If it polls USB 3.0 ports > at a lower rate than USB 2.0 ports, perhaps that could explain the > difference. The kernel does not poll USB ports. At least, not for UHCI, OHCI, EHCI, or xHCI. > I re-tested today with kernel 3.17-rc6 (on Lubuntu 12.04.5) and the USB 3.0 > result is back down to ~0.63MB/sec: > # sg_rbuf --buffer=524288 -v -t -q /dev/sg5 > Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 > READ BUFFER reports: buffer capacity=983040, offset boundary=0 > time to read data from buffer was 332.637465 secs, 0.63 MB/sec > Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) Again, bisection should help. > For someone with no actual USB 1.1 drive, could connecting a USB 2.0 drive > through an old USB 1.1 hub (then to a USB 2.0 or 3.0 port) work for > testing? USB 1.1 hubs are probably still relatively easy to come by. Yes, that would work. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On Thu, 25 Sep 2014 11:15:40 -0400 (EDT) Alan Stern wrote: > On Wed, 24 Sep 2014, Mark Knibbs wrote: > > > On Wed, 24 Sep 2014 11:37:11 -0400 (EDT) > > Alan Stern wrote: > > > > > On Wed, 24 Sep 2014, Mark Knibbs wrote: > > > > > > > I did some benchmarks to check the maximum transfer rate of a > > > > USB-to-SCSI > > > > converter. The converter is USB 1.1, so limited to the 12Mbps full speed > > > > rate. The performance when connected to a USB 3.0 port is significantly > > > > worse than when connected to a USB 2.0 port, about 26.5% slower > > > > (0.63MB/sec > > > > vs 0.86MB/sec). > > > > > > > > The USB 3.0 port is provided by an ExpressCard which has a Renesas > > > > controller. It doesn't seem to be defective because I can get 138MB/sec > > > > from a USB 3.0 hard disk. lspci shows > > > > 05:00.0 USB Controller: Renesas Technology Corp. Device 0015 (rev 02) > > > > > > > > I didn't test with an unmodified mainline kernel, but the issue is > > > > present > > > > with both Ubuntu kernel 3.0 and Debian 3.14 (booted from Kali Linux live > > > > DVD). > > > > > > > > I used sg_rbuf from the sg3-utils package. That issues READ BUFFER > > > > commands > > > > instead of reading data from disk, so the result should be closer to the > > > > maximum achievable. The USB-SCSI converter was a Newer Technology uSCSI > > > > connected to an HP 2600fx MO drive. > > > > ... > > > > Any ideas what the reason for the discrepancy might be? Can anyone else > > > > reproduce it? I guess USB 1.1-only devices aren't that common nowadays. > > > > > > You might be able to get more detailed timings if you collect usbmon > > > traces of the two tests. They won't answer your question but they may > > > help point in a particular direction. > > > > > > The xhci-hcd driver has been under active development. For the best > > > results, you really should use the most up-to-date version of the > > > kernel. > > > > Thanks, I booted a Knoppix live DVD (kernel 3.16.2) and ran the tests > > again. The USB 3.0 port rate is now about 0.75MB/sec; some improvement but > > still significantly lower than the USB 2.0 port figure. > > > > Connected to USB 2.0: > > # sg_rbuf --buffer=524288 -q -t -v /dev/sg2 > > Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 > > READ BUFFER reports: buffer capacity=983040, offset boundary=0 > > time to read data from buffer was 242.800446 secs, 0.86 MB/sec > > Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) > > > > Connected to USB 3.0: > > # sg_rbuf --buffer=524288 -q -t -v /dev/sg2 > > Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 > > READ BUFFER reports: buffer capacity=983040, offset boundary=0 > > time to read data from buffer was 280.701167 secs, 0.75 MB/sec > > Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) > > > > > > I captured usbmon logs for this command: > > # sg_rbuf --buffer=524288 -q -t -v --size=16MiB /dev/sg2 > > > > Each is a little under 16KB. Hopefully it's not too annoying to paste them > > here... > > Well, the traces are a little informative but not very. > > The transfers are broken up into 524288-byte segments (not surprising, > since that's what you told sg_rbuf to do). With the USB-2 controller, > each transfer took a uniform 606 ms. With the USB-3 controller, the > transfers varied between roughly 650 ms and 770 ms. > > You can calculate these values for yourself, if you are interested. > Here's how. > > The submission and completion of each 512-KB transfer are indicated by > lines looking like these: > > > USB 2.0 log: > ... > > 8800ab56ee80 2411529751 S Bi:5:008:2 -115 524288 < > > 8800ab56ee80 2412135377 C Bi:5:008:2 0 524288 = > > > > with 524288 in the sixth column. The second column is a timestamp, in > microseconds. Thus the duration of this transfer was 2412135377 - > 2411529751 = 605626 us, or about 606 ms. > > By comparison, > > > USB 3.0 log: > ... > > 880135223040 2116432829 S Bi:8:002:2 -115 524288 < > > 880135223040 2117202040 C Bi:8:002:2 0 524288 = > > > > This took 2117202040 - 2116432829 = 769211 us, or about 769 ms. > > There are other differences, due to the overhead in starting and > finishing each transfer, but this is the largest component. > > There's no telling the reason for this difference. It's got to be a > hardware issue, though, not a software problem. Maybe your xHCI > controller just isn't optimized for carrying out full-speed transfers. That's a possibility, but the improvement between my initial test with kernel 3.14 and 3.16.2 (0.63MB/sec -> 0.75MB/sec) was obviously down to software. So there could be a lack of testing xhci_hcd with old USB 1.1 devices too. Someone else would really need to reproduce these results though; the different kernels could have been built with dif
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On Wed, 24 Sep 2014, Mark Knibbs wrote: > On Wed, 24 Sep 2014 11:37:11 -0400 (EDT) > Alan Stern wrote: > > > On Wed, 24 Sep 2014, Mark Knibbs wrote: > > > > > I did some benchmarks to check the maximum transfer rate of a USB-to-SCSI > > > converter. The converter is USB 1.1, so limited to the 12Mbps full speed > > > rate. The performance when connected to a USB 3.0 port is significantly > > > worse than when connected to a USB 2.0 port, about 26.5% slower > > > (0.63MB/sec > > > vs 0.86MB/sec). > > > > > > The USB 3.0 port is provided by an ExpressCard which has a Renesas > > > controller. It doesn't seem to be defective because I can get 138MB/sec > > > from a USB 3.0 hard disk. lspci shows > > > 05:00.0 USB Controller: Renesas Technology Corp. Device 0015 (rev 02) > > > > > > I didn't test with an unmodified mainline kernel, but the issue is present > > > with both Ubuntu kernel 3.0 and Debian 3.14 (booted from Kali Linux live > > > DVD). > > > > > > I used sg_rbuf from the sg3-utils package. That issues READ BUFFER > > > commands > > > instead of reading data from disk, so the result should be closer to the > > > maximum achievable. The USB-SCSI converter was a Newer Technology uSCSI > > > connected to an HP 2600fx MO drive. > > > ... > > > Any ideas what the reason for the discrepancy might be? Can anyone else > > > reproduce it? I guess USB 1.1-only devices aren't that common nowadays. > > > > You might be able to get more detailed timings if you collect usbmon > > traces of the two tests. They won't answer your question but they may > > help point in a particular direction. > > > > The xhci-hcd driver has been under active development. For the best > > results, you really should use the most up-to-date version of the > > kernel. > > Thanks, I booted a Knoppix live DVD (kernel 3.16.2) and ran the tests > again. The USB 3.0 port rate is now about 0.75MB/sec; some improvement but > still significantly lower than the USB 2.0 port figure. > > Connected to USB 2.0: > # sg_rbuf --buffer=524288 -q -t -v /dev/sg2 > Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 > READ BUFFER reports: buffer capacity=983040, offset boundary=0 > time to read data from buffer was 242.800446 secs, 0.86 MB/sec > Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) > > Connected to USB 3.0: > # sg_rbuf --buffer=524288 -q -t -v /dev/sg2 > Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 > READ BUFFER reports: buffer capacity=983040, offset boundary=0 > time to read data from buffer was 280.701167 secs, 0.75 MB/sec > Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) > > > I captured usbmon logs for this command: > # sg_rbuf --buffer=524288 -q -t -v --size=16MiB /dev/sg2 > > Each is a little under 16KB. Hopefully it's not too annoying to paste them > here... Well, the traces are a little informative but not very. The transfers are broken up into 524288-byte segments (not surprising, since that's what you told sg_rbuf to do). With the USB-2 controller, each transfer took a uniform 606 ms. With the USB-3 controller, the transfers varied between roughly 650 ms and 770 ms. You can calculate these values for yourself, if you are interested. Here's how. The submission and completion of each 512-KB transfer are indicated by lines looking like these: > USB 2.0 log: ... > 8800ab56ee80 2411529751 S Bi:5:008:2 -115 524288 < > 8800ab56ee80 2412135377 C Bi:5:008:2 0 524288 = > with 524288 in the sixth column. The second column is a timestamp, in microseconds. Thus the duration of this transfer was 2412135377 - 2411529751 = 605626 us, or about 606 ms. By comparison, > USB 3.0 log: ... > 880135223040 2116432829 S Bi:8:002:2 -115 524288 < > 880135223040 2117202040 C Bi:8:002:2 0 524288 = > This took 2117202040 - 2116432829 = 769211 us, or about 769 ms. There are other differences, due to the overhead in starting and finishing each transfer, but this is the largest component. There's no telling the reason for this difference. It's got to be a hardware issue, though, not a software problem. Maybe your xHCI controller just isn't optimized for carrying out full-speed transfers. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On Wed, 24 Sep 2014 11:37:11 -0400 (EDT)
Alan Stern wrote:
> On Wed, 24 Sep 2014, Mark Knibbs wrote:
>
> > I did some benchmarks to check the maximum transfer rate of a USB-to-SCSI
> > converter. The converter is USB 1.1, so limited to the 12Mbps full speed
> > rate. The performance when connected to a USB 3.0 port is significantly
> > worse than when connected to a USB 2.0 port, about 26.5% slower (0.63MB/sec
> > vs 0.86MB/sec).
> >
> > The USB 3.0 port is provided by an ExpressCard which has a Renesas
> > controller. It doesn't seem to be defective because I can get 138MB/sec
> > from a USB 3.0 hard disk. lspci shows
> > 05:00.0 USB Controller: Renesas Technology Corp. Device 0015 (rev 02)
> >
> > I didn't test with an unmodified mainline kernel, but the issue is present
> > with both Ubuntu kernel 3.0 and Debian 3.14 (booted from Kali Linux live
> > DVD).
> >
> > I used sg_rbuf from the sg3-utils package. That issues READ BUFFER commands
> > instead of reading data from disk, so the result should be closer to the
> > maximum achievable. The USB-SCSI converter was a Newer Technology uSCSI
> > connected to an HP 2600fx MO drive.
> > ...
> > Any ideas what the reason for the discrepancy might be? Can anyone else
> > reproduce it? I guess USB 1.1-only devices aren't that common nowadays.
>
> You might be able to get more detailed timings if you collect usbmon
> traces of the two tests. They won't answer your question but they may
> help point in a particular direction.
>
> The xhci-hcd driver has been under active development. For the best
> results, you really should use the most up-to-date version of the
> kernel.
Thanks, I booted a Knoppix live DVD (kernel 3.16.2) and ran the tests
again. The USB 3.0 port rate is now about 0.75MB/sec; some improvement but
still significantly lower than the USB 2.0 port figure.
Connected to USB 2.0:
# sg_rbuf --buffer=524288 -q -t -v /dev/sg2
Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00
READ BUFFER reports: buffer capacity=983040, offset boundary=0
time to read data from buffer was 242.800446 secs, 0.86 MB/sec
Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes)
Connected to USB 3.0:
# sg_rbuf --buffer=524288 -q -t -v /dev/sg2
Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00
READ BUFFER reports: buffer capacity=983040, offset boundary=0
time to read data from buffer was 280.701167 secs, 0.75 MB/sec
Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes)
I captured usbmon logs for this command:
# sg_rbuf --buffer=524288 -q -t -v --size=16MiB /dev/sg2
Each is a little under 16KB. Hopefully it's not too annoying to paste them
here...
USB 2.0 log:
8800ab56e940 2411521097 S Bo:5:008:1 -115 31 = 55534243 4900 0400
8a3c 0300 0004 00
8800ab56e940 2411522718 C Bo:5:008:1 0 31 >
8800ab56ee80 2411522753 S Bi:5:008:2 -115 4 <
8800ab56ee80 2411526695 C Bi:5:008:2 0 4 = 000f
8800ab56e940 2411526722 S Bi:5:008:2 -115 13 <
8800ab56e940 2411528714 C Bi:5:008:2 0 13 = 55534253 4900 00
8800ab56e940 2411528859 S Bo:5:008:1 -115 31 = 55534243 4a00 0800
8a3c 0200 0008 00
8800ab56e940 2411529716 C Bo:5:008:1 0 31 >
8800ab56ee80 2411529751 S Bi:5:008:2 -115 524288 <
8800ab56ee80 2412135377 C Bi:5:008:2 0 524288 =
8800ab56e940 2412135413 S Bi:5:008:2 -115 13 <
8800ab56e940 2412135718 C Bi:5:008:2 0 13 = 55534253 4a00 00
8800ab56e940 2412136537 S Bo:5:008:1 -115 31 = 55534243 4b00 0800
8a3c 0200 0008 00
8800ab56e940 2412136719 C Bo:5:008:1 0 31 >
8800ab56ee80 2412136744 S Bi:5:008:2 -115 524288 <
8800ab56ee80 2412741454 C Bi:5:008:2 0 524288 =
8800ab56e940 2412741481 S Bi:5:008:2 -115 13 <
8800ab56e940 2412743719 C Bi:5:008:2 0 13 = 55534253 4b00 00
8800ab56e940 2412744251 S Bo:5:008:1 -115 31 = 55534243 4c00 0800
8a3c 0200 0008 00
8800ab56e940 2412744719 C Bo:5:008:1 0 31 >
8800ab56ee80 2412744742 S Bi:5:008:2 -115 524288 <
8800ab56ee80 2413350166 C Bi:5:008:2 0 524288 =
8800ab56e940 2413350199 S Bi:5:008:2 -115 13 <
8800ab56e940 2413350745 C Bi:5:008:2 0 13 = 55534253 4c00 00
8800ab56e940 2413351235 S Bo:5:008:1 -115 31 = 55534243 4d00 0800
8a3c 0200 0008 00
8800ab56e940 2413351743 C Bo:5:008:1 0 31 >
8800ab56ee80 2413351774 S Bi:5:008:2 -115 524288 <
8800ab56ee80 2413956164 C Bi:5:008:2 0 524288 =
8800ab56e940 2413956196 S Bi:5:008:2 -115 13 <
8800ab56e940 2413957740 C Bi:5:008:2 0 13 = 55534253
Re: Poor performance with USB 1.1 drive connected to USB 3.0 port
On Wed, 24 Sep 2014, Mark Knibbs wrote: > Hi, > > I did some benchmarks to check the maximum transfer rate of a USB-to-SCSI > converter. The converter is USB 1.1, so limited to the 12Mbps full speed > rate. The performance when connected to a USB 3.0 port is significantly > worse than when connected to a USB 2.0 port, about 26.5% slower (0.63MB/sec > vs 0.86MB/sec). > > The USB 3.0 port is provided by an ExpressCard which has a Renesas > controller. It doesn't seem to be defective because I can get 138MB/sec > from a USB 3.0 hard disk. lspci shows > 05:00.0 USB Controller: Renesas Technology Corp. Device 0015 (rev 02) > > I didn't test with an unmodified mainline kernel, but the issue is present > with both Ubuntu kernel 3.0 and Debian 3.14 (booted from Kali Linux live > DVD). > > I used sg_rbuf from the sg3-utils package. That issues READ BUFFER commands > instead of reading data from disk, so the result should be closer to the > maximum achievable. The USB-SCSI converter was a Newer Technology uSCSI > connected to an HP 2600fx MO drive. > > In a USB 2.0 port: > > # sg_rbuf --buffer=524288 -v -t -q /dev/sg3 > Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 > READ BUFFER reports: buffer capacity=983040, offset boundary=0 > time to read data from buffer was 242.800241 secs, 0.86 MB/sec > Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) > > # sg_rbuf --buffer=524288 -v -t -q /dev/sg3 > Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 > READ BUFFER reports: buffer capacity=983040, offset boundary=0 > time to read data from buffer was 242.800230 secs, 0.86 MB/sec > Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) > > > In a USB 3.0 port: > > # sg_rbuf --buffer=524288 -v -t -q /dev/sg3 > Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 > READ BUFFER reports: buffer capacity=983040, offset boundary=0 > time to read data from buffer was 330.311337 secs, 0.63 MB/sec > Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) > > # sg_rbuf --buffer=524288 -v -t -q /dev/sg3 > Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 > READ BUFFER reports: buffer capacity=983040, offset boundary=0 > time to read data from buffer was 330.388556 secs, 0.63 MB/sec > Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) > > > By comparison, I checked the transfer rate in native Windows (Vista) with > the WinSAT program. That reported 0.66MB/sec for both USB 2.0 and 3.0 > ports. (WinSAT reads data from disk, probably in smaller chunks than 512KB. > There's no sg_rbuf executable in the Windows sg3_utils archive.) > > Any ideas what the reason for the discrepancy might be? Can anyone else > reproduce it? I guess USB 1.1-only devices aren't that common nowadays. You might be able to get more detailed timings if you collect usbmon traces of the two tests. They won't answer your question but they may help point in a particular direction. The xhci-hcd driver has been under active development. For the best results, you really should use the most up-to-date version of the kernel. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Poor performance with USB 1.1 drive connected to USB 3.0 port
Hi, I did some benchmarks to check the maximum transfer rate of a USB-to-SCSI converter. The converter is USB 1.1, so limited to the 12Mbps full speed rate. The performance when connected to a USB 3.0 port is significantly worse than when connected to a USB 2.0 port, about 26.5% slower (0.63MB/sec vs 0.86MB/sec). The USB 3.0 port is provided by an ExpressCard which has a Renesas controller. It doesn't seem to be defective because I can get 138MB/sec from a USB 3.0 hard disk. lspci shows 05:00.0 USB Controller: Renesas Technology Corp. Device 0015 (rev 02) I didn't test with an unmodified mainline kernel, but the issue is present with both Ubuntu kernel 3.0 and Debian 3.14 (booted from Kali Linux live DVD). I used sg_rbuf from the sg3-utils package. That issues READ BUFFER commands instead of reading data from disk, so the result should be closer to the maximum achievable. The USB-SCSI converter was a Newer Technology uSCSI connected to an HP 2600fx MO drive. In a USB 2.0 port: # sg_rbuf --buffer=524288 -v -t -q /dev/sg3 Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 READ BUFFER reports: buffer capacity=983040, offset boundary=0 time to read data from buffer was 242.800241 secs, 0.86 MB/sec Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) # sg_rbuf --buffer=524288 -v -t -q /dev/sg3 Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 READ BUFFER reports: buffer capacity=983040, offset boundary=0 time to read data from buffer was 242.800230 secs, 0.86 MB/sec Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) In a USB 3.0 port: # sg_rbuf --buffer=524288 -v -t -q /dev/sg3 Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 READ BUFFER reports: buffer capacity=983040, offset boundary=0 time to read data from buffer was 330.311337 secs, 0.63 MB/sec Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) # sg_rbuf --buffer=524288 -v -t -q /dev/sg3 Read buffer cdb: 3c 03 00 00 00 00 00 00 04 00 READ BUFFER reports: buffer capacity=983040, offset boundary=0 time to read data from buffer was 330.388556 secs, 0.63 MB/sec Read 200 MiB (actual: 209715200 bytes), buffer size=512 KiB (524288 bytes) By comparison, I checked the transfer rate in native Windows (Vista) with the WinSAT program. That reported 0.66MB/sec for both USB 2.0 and 3.0 ports. (WinSAT reads data from disk, probably in smaller chunks than 512KB. There's no sg_rbuf executable in the Windows sg3_utils archive.) Any ideas what the reason for the discrepancy might be? Can anyone else reproduce it? I guess USB 1.1-only devices aren't that common nowadays. Mark -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
