Problems (#1) - Lots of invalid packets and high cpu usage (#38) - Message List
first of all I have to say that CWiid is a great application. With lots of help I managed to use it on a wearable computer with an ARM processor. (For those who are interested in cross compiling I wrote a short howto: CrossCompile )
the only remaining problem is that wminput produces lots of "invalid packet type" messages (the more I move it, the more of them occur) but works properly apart from that. Additionally wminput uses about 30% of the capacity of the 400MHz XScale cpu (using the acc tracker plugin and moving the wiimote around). Perhaps this is related to the high amount of reported errors.
These problems occur both with v0.5.03 and cvs trunk r124. Other versions were not examined to that effect.
So my questions are:
- What could be the reason for the error messages?
- Do the error messages drive up cpu usage?
- Is it possible to save cpu usage somewhere else in wminput?
Andreas, Thanks for writing up what you've learned - I've added a link to your page on the start page.
- I don't think I've ever seen an invalid packet type message. That message is generated if the bluetooth packet header doesn't look right, but the message is used anyway. Is the XScale a big-endian processor? My first guess would be an endian issue.
- The error message could drive it up some - wouldn't guess more than 5% or so. Comment lines 89-91 in libcwiid/thread.c (r124) and recompile to find out.
- libcwiid and wminput are pretty lean. I'm sure there are places where they could be improved, but I don't expect to find huge optimizations. If I have a chance over the next week or so, I'll run it under a profiler and see if anything looks strange. Implementing the driver as a kernel module should yield significant speed improvements, but that's a loooooong way off.
Post the effects of eliminating the error messages, and we'll go from there.dsmith06/08/07 11:31:16 (6 years ago)
Thanks for the suggestions.
agoeb06/18/07 15:32:43 (6 years ago)
- The XScale supports both big and little endian data representation. Default is little endian, so this should be no problem.
- The error message output was the time consuming part. Redirecting stderr to /dev/null did not decrease cpu usage, but commenting out the lines you mentioned led to a maximum value of about 10%, which is a reduction of 2/3.
- You don't need to do the profiling if it is to time consuming for you. The improvement I gained with my patch should be enough for working comfortably.
With version 0.6.00 I encounter the same problems - even with the first-byte-check and error message removed. If I randomly and quickly move the wiimote, the cpu usage rises up to over 30%. The implementation as a kernel module is scheduled to v2.0, so is there anything I can do in the meantime to get a better performance?agoeb09/03/07 13:46:18 (6 years ago)
I'm having similar issues on a MIPS-based system. Which kernel, BlueZ version and hardware are you using? I don't know which component to blame yet.Exirion07/04/07 13:42:42 (6 years ago)