From: "Leonardo E. Reiter" <lreiter@win4lin.com>
To: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Performance issues with -usb
Date: Sat, 29 Jul 2006 14:22:43 -0400 [thread overview]
Message-ID: <44CBA773.4040007@win4lin.com> (raw)
In-Reply-To: <44C49A23.6010103@wasp.net.au>
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
next prev parent reply other threads:[~2006-07-29 18:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-24 9:06 [Qemu-devel] Performance issues with -usb Brad Campbell
2006-07-24 9:23 ` Lonnie Mendez
2006-07-24 10:00 ` Brad Campbell
2006-07-29 18:22 ` Leonardo E. Reiter [this message]
2006-07-29 18:42 ` malc
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=44CBA773.4040007@win4lin.com \
--to=lreiter@win4lin.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.