From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G6tSZ-0004uj-Mp for qemu-devel@nongnu.org; Sat, 29 Jul 2006 14:22:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1G6tSY-0004tz-4L for qemu-devel@nongnu.org; Sat, 29 Jul 2006 14:22:47 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G6tSX-0004tu-C7 for qemu-devel@nongnu.org; Sat, 29 Jul 2006 14:22:45 -0400 Received: from [204.127.225.92] (helo=alnrmhc12.comcast.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1G6tUn-0000x1-TS for qemu-devel@nongnu.org; Sat, 29 Jul 2006 14:25:06 -0400 Message-ID: <44CBA773.4040007@win4lin.com> Date: Sat, 29 Jul 2006 14:22:43 -0400 From: "Leonardo E. Reiter" MIME-Version: 1.0 Subject: Re: [Qemu-devel] Performance issues with -usb References: <44C48DAD.9010301@wasp.net.au> <1153733038.4270.8.camel@vaio> <44C49A23.6010103@wasp.net.au> In-Reply-To: <44C49A23.6010103@wasp.net.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Brad, I think the 0x20 (32ms) value might be fine for something like VNC display, but on a local display the mouse response is noticeably slow (for me at least.) I tried using 0x0a (10), same as the plain USB mouse, but the idle CPU utilization was still around 10%. What is really odd is that this was not a problem in older versions of QEMU, unless I'm reading data incorrectly. Do you know what else might have changed? I will look as well and see if I can apply some logic to this. I suspect it's probably something with the new clock mechanism, but it still doesn't make a lot of sense to me. I've looked at both Windows 2000 and XP guests and seen similar results so far with the latest QEMU/KQEMU combination. The good news at least is that the 0x0a interval seems very smooth even on a local display, but certainly is much friendlier than the CVS version on the CPU. Still, 10% idle usage is quite high. If it can't logically be fixed to provide both a) low idle CPU and b) smooth local display response, then I might just post a runtime option patch allowing the user to configure the interval on the command line. I'm not sure how correct that is, but it would be useful to me at least. - Leo Reiter Brad Campbell wrote: > Lonnie Mendez wrote: > >> Perhaps tweaking the value of ep_bInterval for the tablet's status >> change endpoint would help? The endpoint descriptor for the tablet >> currently has this at 3 milliseconds. The hid mouse reports a 10 >> millisecond polling interval. > > Indeed. I'm not quite sure how or why I did that in the 1st place as the > tablet started life as a copy of the mouse in any case. > > I've had good drag through the specs and all the data sheets for mouse > chips I could find out there and most of them seem to recommend a value > no faster than 8ms. > > This drops the cpu utilisation of a Windows guest while idle about 75% > when using -usbdevice tablet > I've not noticed any change in usability or mouse responsiveness. > (I played with values up to 0xFF but after about 0x20 there seemed to be > immeasurable/no difference) > -- Leonardo E. Reiter Vice President of Product Development, CTO Win4Lin, Inc. Virtual Computing that means Business Main: +1 512 339 7979 Fax: +1 512 532 6501 http://www.win4lin.com