On Thu, 25 Sep 2014 11:15:40 -0400 (EDT) Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Wed, 24 Sep 2014, Mark Knibbs wrote: > > > On Wed, 24 Sep 2014 11:37:11 -0400 (EDT) > > Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> 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: > ... > > ffff8800ab56ee80 2411529751 S Bi:5:008:2 -115 524288 < > > ffff8800ab56ee80 2412135377 C Bi:5:008:2 0 524288 = aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa > > 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: > ... > > ffff880135223040 2116432829 S Bi:8:002:2 -115 524288 < > > ffff880135223040 2117202040 C Bi:8:002:2 0 524288 = aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa aaaaaaaa > > 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 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. 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) 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. Mark -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html