On Mon, 13 Jan 2014, Alan Ott 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? The analyzer clearly indicates that something is wrong on the peripheral (as opposed to the host). Since the gadget driver seems simple and straightforward, most likely the UDC driver is the cause (or the UDC hardware). You can test this by adding a few pr_debug statements at appropriate places in f_sourcesink.c. Certainly one every time the completion routine gets called, maybe also one after each request submission. You might want to combine this with changing the size of the buffer, so that the 8 packets/buffer doesn't confused with the 8 packets/delay. You might also want to try asking the driver's authors, who appear to be Toshiharu Okada <toshiharu-linux@xxxxxxxxxxxxxxx> and Tomoya MORINAGA <tomoya-linux@xxxxxxxxxxxxxxx>, judging by the git log. Alan Stern -- 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
