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
