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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).