Toshiharu and Tomoya,
I sent the email below to linux-usb today in regards to some performance
issues I'm seeing with the EG20T (pch_udc) driver.
I appreciate any insight you may have.
Alan.
On 01/13/2014 03:20 PM, 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?
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
