On 01/14/2014 12:08 AM, Rajaram R wrote:
I guess it is something to do with the buffer size of the gadget
driver. Could you please try change the buffer size to 16K and confirm
if the delay is shifting ? In this case your delay should be after 31
transfers...
===============
66 static struct usb_zero_options gzero_options = {
67 .isoc_interval = 4,
68 .isoc_maxpacket = 1024,
69 .bulk_buflen = 4096, =========================> change to 16K
70 .qlen = 32,
71 };
===============
Hi Rajram,
Yes, this does as you suspected. I now get 222Mbit/sec of data transfer.
The amount of time lost during each period of NAKs also increased, with
between 100 and 131us lost every 32nd transaction.
So the part I misunderstood is that buflen (which can be set as a
parameter to g_zero) is the number of bytes in each transfer. I wrongly
assumed f_sourcesink was sending 512-byte single-transaction transfers
(because the data would look the same).
It looks like the extended delay time is happening once every transfer,
and in looking at the driver it looks like it's because only one
transfer can be active (queued) in the hardware at once. It all adds up now.
Thank you all for your help.
Alan.
--
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
