On 10/18/2012 1:16 AM, Paul Zimmerman wrote:
From: Sarah Sharp [mailto:sarah.a.sharp@xxxxxxxxxxxxxxx]
Sent: Wednesday, October 17, 2012 12:09 PM
On Wed, Oct 17, 2012 at 06:49:14PM +0000, Paul Zimmerman wrote:
From: linux-usb-owner@xxxxxxxxxxxxxxx [mailto:linux-usb-owner@xxxxxxxxxxxxxxx] On Behalf Of Pratyush Anand
Sent: Wednesday, October 17, 2012 6:13 AM
I was trying to test max bulk through put capability of my usb3.0
device. Bulk IN EP Companion descriptor's bMaxburst is 15 in my gadget.
My host controller is TUSB7340.
I see, that Device Sends ERDY with NumP=16.
Host sends ACK with NumP=4. I noticed that xhci driver programs Max
Burst Size same as that of reported by companion descriptor. So, what
does it mean, host controller's Max Burst is 4 only? So, even if driver
programs 15, it is limited by 3.
If yes, Does anybody know about any host controller supporting Max Burst
as 16 on Bulk EP?
The NumP=4 from the host probably means that the host only has buffer
space for 4 1K packets. 4K is the page size, so maybe the host was given a
scatter-gather list made up of single pages (just a guess). Or else the host
system just cannot empty the buffers quick enough to keep up.
The SCSI layer and mass storage driver usually queues a scatter-gather
list of 4K entries for the data phase. The Linux xHCI driver turns each
sg-list entry into one TRB, and chains them all into one TD. So it's up
to the host controller to fetch multiple TRBs and set the NumP field
appropriately.
It's possible the host controller only wants to fetch the current TRB's
worth of data. We could attempt to collasce adjacent sg-list entries,
but I would have to look into whether that's possible, or if the upper
layer is already doing that when it creates the sg-list.
I think, here case is something different, because each submitted URB is
of size 409600 bytes. Is it still possible that each TRB submitted is of
size 4K only?
I am using usbtest/testusb under Linux to measure performance. I did
some modification in zero gadget/usbtest to accept different
bMaxburst/pattern etc for each supported EP.
On my EVB I do like this:
# insmod g_zero.ko buflen=409600 pattern=2 bulk_maxburst_in=15
I did some modification in usbtest too, to support pattern=2 (no check
for data integrity)
# insmod usbtest.ko pattern=2
# ./testusb -a -c 1000 -t 2 -s 409600 -g 1
Just to notice that, same combination of host and device supports burst
size of 16 on ISOC IN EP. With the following, I get 3Gbps end to end
throughput.
@EVB:
# insmod g_zero.ko pattern=2 isoc_interval_in=1 isoc_mult_in=2
isoc_maxburst_in=15
@Host:
#./testusb -a -c 1000 -t 16 -g 10 -s 98304
What is the host OS and driver? We have found that the Linux xHCI driver
does not perform very well compared to the MCCI xHCI driver under
Windows (which AFAIK is the xHCI driver you usually get when you buy a
NEC/Renesas host adapter). Did you get a Windows xHCI driver along with
your TUSB7340 adapter?
My host PC is:
PC with fedora 17 (kernel 3.5.4, Pentium(R) Dual Core E5400 @ 2.70 GHz,
tusb7340evm connected at PCIe GEN2 port).
Yep, the Linux xHCI driver performance needs improvement. That's next
on my todo list after I slog through my current bug list.
Hi Sarah,
Actually, I think I misspoke. I suspect it's actually the USB mass-storage
class driver, or the layers above it, that is responsible for the slowness.
The performance under Windows is comparable to Linux, until you
replace the standard USB mass-storage class driver with the one from
MCCI (in addition to their xHCI driver). And AFAIK you don't get that
driver when you buy a NEC/Renesas add-in card.
Which reminds me, I need to do a performance test under Windows
8, to see how it compares using its built-in USB 3.0 support.
Regards
Pratyush
--
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
