On Thu, Nov 7, 2013 at 12:47 PM, Alan Ott <alan@xxxxxxxxxxx> wrote: > On 11/05/2013 05:39 PM, Cliff Brake wrote: >> >> On Tue, Nov 5, 2013 at 9:57 AM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> >> wrote: >>> >>> You might be better off writing a special-purpose userspace driver, using >>> libusb, instead of relying on the HID driver. That would allow you to handle >>> your data more efficiently, and with interrupts enabled. >> >> We tried this early on, but ran into other performance problems. >> Thanks for the idea, we may re-visit this. > > > When you say "performance problems" and libusb... how many active transfers > did you keep submitted at one time in your libusb application? > > Greg recently said on this list: >> >> You should be able to hit USB "line speed" from userspace >> if you just are reading/writing bulk data with enough transferrs in >> flight. Thanks for the additional information, and all the help -- we just happened to find a solution. In the function trace, we noticed that the hiddev calls were taking most of the time and causing expensive function calls for every byte. Since we are using hidraw to access the usb data, we simply disabled the hiddev kernel config option, and now its working great. In the 3.0 kernel, we did not have hiddev enabled, so the kernel upgrade from 3.0 to 3.12 has definitely helped. The kernel tracer is definitely a handy to have! Thanks, Cliff > > > Alan. > -- ================= http://bec-systems.com -- 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
