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. Alan Stern -- 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
