Hi
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 };
===============
Rajaram
On Tue, Jan 14, 2014 at 1:50 AM, Alan Ott <alan@xxxxxxxxxxx> wrote:
> Hi all,
>
> I have an EG20T-based board and have some issues with performance on the USB
> device interface.
>
> I made a libusb test program (using the async interface)[0] to read data
> from the EG20T's USB device port which has the gadget zero source/sink
> function bound. In theory, one would hope this would give the fastest
> real-world results for the hardware connected.
>
> The test program submits 32 IN transfers and re-submits on transfer
> completion, counting received packets.
>
> From running my test program for a few minutes I get the following:
> elapsed: 548.468416 seconds
> packets: 21503334
> packets/sec: 39206.148199
> bytes/sec: 20073547.877732
> MBit/sec: 160.588383
>
> 160MBit/sec isn't terrible, but I hoped for better. A USB analyzer shows 7
> transactions happening quickly (with about 14us separating them), but every
> 8th transaction, the EG20T will NAK between 20-80 times[1], losing
> 50-100us[2].
>
> This delay happens every 8th transaction without fail[3].
>
> I've looked at the following:
> 1. The f_sourcesink.c function it queues up 8 responses at the beginning.
> Changing this number up or down had no effect.
> 2. Analysis of pch_udc.c doesn't show anything which would obviously cause a
> delay every 8th packet.
> 3. f_eem seems to have roughly the same performance with ping -f -s 64000
> (160Mbit/sec).
>
> The CPU load of the gadget-side Atom PC sits very close to zero.
>
> System Details:
> Linux 3.13.0-rc7 (With a defconfig from Yocto for Intel Crownbay)
> Intel Atom E680 with EG20T
>
> I seem to have eliminated everything on the host side, since the host is
> asking for data, and the device is saying it doesn't have any for up to
> 100us at a time.
>
> What am I missing?
>
> Alan.
>
> [0] http://www.signal11.us/~alan/recv.c
> [1] The number of NAKs not important and doesn't correlate to the amount of
> time spent NAK-ing.
> [2] Analyzer screenshots:
> http://www.signal11.us/~alan/nak.png
> http://www.signal11.us/~alan/nak_open.png
> [3] Often it looks like it's aligned to a SOF packet, but that's only
> because when you delay 100us, the odds are good you will be NAK-ing when a
> SOF packet arrives (every 125us). Sometimes the NAK-ing will start before
> the SOF and sometimes after.
>
> --
> 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
--
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
