[Qemu-devel] Performance issues with -usb

[Qemu-devel] Performance issues with -usb

[Brad Campbell]

G'day all,

Just a diary note or similar.

I've been playing with skype under win2k under qemu with -kernel-kqemu and the alsa audio driver.

1st. The user-net driver appears to be a problem for skype but the tap driver works nicely.

2nd. I was having awful problems with the audio. The app was reporting failures of either the dac or 
adc apparently randomly and when it did work it was rather intermittent.

I noticed that with -usb -usbdevice tablet that qemu sits at about 20% cpu usage (on this machine 
which is a Pentium-M 1.2G which idles at 600Mhz) whereas without -usb qemu idles completely.

In addition to this, without -usb.. skype works almost perfectly. There is the occasional audio 
glitch (as you would expect) but it does everything it is supposed to do quite nicely.

I'm using all the latest gear. A 2.6.18-rc2 host kernel, Latest Qemu CVS and the -pre9 kernel 
accelerator. Win2k SP4 as a guest with either 256 or 384M of ram depending on my mood :)

I'm going to have a dig around in the USB stuff when I get the chance, but it's more of a fyi and 
for google that I post it here.

Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] Performance issues with -usb

[Lonnie Mendez]

On Mon, 2006-07-24 at 13:06 +0400, Brad Campbell wrote:
> G'day all,
> 
> Just a diary note or similar.
> 
> I've been playing with skype under win2k under qemu with -kernel-kqemu and the alsa audio driver.
> 
> 1st. The user-net driver appears to be a problem for skype but the tap driver works nicely.
> 
> 2nd. I was having awful problems with the audio. The app was reporting failures of either the dac or 
> adc apparently randomly and when it did work it was rather intermittent.
> 
> I noticed that with -usb -usbdevice tablet that qemu sits at about 20% cpu usage (on this machine 
> which is a Pentium-M 1.2G which idles at 600Mhz) whereas without -usb qemu idles completely.
> 
> In addition to this, without -usb.. skype works almost perfectly. There is the occasional audio 
> glitch (as you would expect) but it does everything it is supposed to do quite nicely.
> 
> I'm using all the latest gear. A 2.6.18-rc2 host kernel, Latest Qemu CVS and the -pre9 kernel 
> accelerator. Win2k SP4 as a guest with either 256 or 384M of ram depending on my mood :)
> 
> I'm going to have a dig around in the USB stuff when I get the chance, but it's more of a fyi and 
> for google that I post it here.

   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.

excerpt from qemu_tablet_config_descriptor in hw/usb-hid.c:

        /* one endpoint (status change endpoint) */
        0x07,       /*  u8  ep_bLength; */
        0x05,       /*  u8  ep_bDescriptorType; Endpoint */
        0x81,       /*  u8  ep_bEndpointAddress; IN Endpoint 1 */
        0x03,       /*  u8  ep_bmAttributes; Interrupt */
        0x08, 0x00, /*  u16 ep_wMaxPacketSize; */
        0x03,       /*  u8  ep_bInterval; (255ms -- usb 2.0 spec) */

Re: [Qemu-devel] Performance issues with -usb

[Brad Campbell]

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)


Index: hw/usb-hid.c
===================================================================
RCS file: /cvsroot/qemu/qemu/hw/usb-hid.c,v
retrieving revision 1.5
diff -u -r1.5 usb-hid.c
--- hw/usb-hid.c        19 Jul 2006 18:06:15 -0000      1.5
+++ hw/usb-hid.c        24 Jul 2006 09:55:22 -0000
@@ -169,7 +169,7 @@
         0x81,       /*  u8  ep_bEndpointAddress; IN Endpoint 1 */
         0x03,       /*  u8  ep_bmAttributes; Interrupt */
         0x08, 0x00, /*  u16 ep_wMaxPacketSize; */
-       0x03,       /*  u8  ep_bInterval; (255ms -- usb 2.0 spec) */
+       0x20,       /*  u8  ep_bInterval; (255ms -- usb 2.0 spec) */


Brad
-- 
"Human beings, who are almost unique in having the ability
to learn from the experience of others, are also remarkable
for their apparent disinclination to do so." -- Douglas Adams

Re: [Qemu-devel] Performance issues with -usb

[Leonardo E. Reiter]

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

Re: [Qemu-devel] Performance issues with -usb

[malc]

On Sat, 29 Jul 2006, Leonardo E. Reiter wrote:

> 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.

Sometime after usbtablet hit the CVS i tried it out and the first thing i
noticed was the cpu load. On june 12 i tried to figure out if one of the
patch authors (Anthony Liguori) is aware of the situation. So it's not
related to gettimeofday switchover.

--
mailto:malc@pulsesoft.com