Toby Gray wrote: > The only numbers which would probably make sense to others are that we > noticed that there was a long time between the short packet of the end > of a transfer and the host issuing the next IN token for that endpoint. > The gap is multiple milliseconds in length on WinCE, but not when the > same board is running a Linux image.
There must be about a dozen causes behind that, and Libusbx's event handling has to be about #11 on that list in terms of importance. My guess is that the #1 cause is the design of the USB host controller driver. The WinCE USB stack is primitive. It hasn't received anywhere NEAR the attention or the real-world stress testing that either the Windows or the Linux USB stack has had. I suspect, for example, that it only asks for an interrupt at end of frame, and it submits the next frame's schedule immediately. In that case, unless you have multiple concurrent requests, you will NEVER get more than one request every two milliseconds. It's impossible, and there is nothing you can do in user-mode code to fix that. > We have finally got around to making sure that we have multiple > concurrent bulk in transfers to eliminate this latency. I know that we > should have been doing this from the start, but higher priority things > had always got in the way and the event handling in Linux was fast > enough for us to get away with it. Sometimes. Even when it works, it's very delicate, and highly dependent on system load. It wouldn't take an awful lot of competing CPU activity to make it break on Linux as well. The ONLY robust solution is multiple pending requests. > So it's now a case of reducing the CPU time that we see in the > processing of events. We've not drilled down fair enough yet to discover > exactly where the time goes. You are free to chase this line of investigation if you want, of course, but it is my educated opinion that you are wasting your time. You are solving a problem that simply cannot be solved in the general case. You are bucking Amdahl's Law here. The libusbx event handling is such a small part of the problem that, even if you completely eliminated all of the libusbx overhead, you would have improved the overall performance so slightly that it makes no difference. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter _______________________________________________ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
