On Fri, 6 Sep 2013, Oleksij Rempel wrote: > Am 06.09.2013 23:09, schrieb Alan Stern: > > On Fri, 6 Sep 2013, Oleksij Rempel wrote: > > > >> Hi Alan, > >> > >> i need more help. > >> > >> We have more test results now. Initial patch was probably fixing > >> fallowing issue - bad performance on EP4/EP3 if Intr transfer is used. > >> It is reproducible only on EHCI, but not reproducible on xHCI controller. > > > > Is this a high-speed device? > > yes > > > What version of the kernel are you using? > > currently it is 3.11.0-rc7-wl-00004-g52e0063, but i can reproduce this > issue with older kernels too. > > >> For example, channel scan function intensively use this endpoints. On > >> xHCI, channel scan is done in 6 seconds. On EHCI it needs 25s. By > >> forcing Bulk transfer on host side, it is possible get same performance > >> on EHCI too. But it isn't working on all controllers because of limited > >> packed size (64B). > >> > >> Dumps are attached. One of them may include some other device, but only > >> ath9k_htc device has EP3 and EP4. > > > > The capture logs show that with EHCI, each endpoint transfers a packet > > every 2.5 ms or so, whereas xHCI transfers 2-3 packets per ms. > > > >> Is it protocol limitation or HC issue? > > > > It's not a protocol limitation. If it were, the xHCI communication > > would be just as slow as EHCI. > > > > One thing that might help: For each endpoint, keep multiple URBs queued > > (try 10) at all times instead of just a single URB. > > > > It's entirely possible that these results are caused by limitations of > > your EHCI hardware. Still, using multiple URBs could yield a > > significant improvement. > > Same issue on two different intel controllers. I'll try some thing > different for comparison. Don't try different hardware. Try submitting multiple URBs. 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
