On Tue, Jan 14, 2014 at 02:06:13PM +0800, Alan Ott wrote:
> 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.
See here, some way to get higher speed with zero gadget.
http://www.spinics.net/lists/linux-usb/msg100588.html
Regards
Pratyush
> --
> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
