From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53988) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMO5x-0001Vo-Jh for qemu-devel@nongnu.org; Tue, 17 May 2011 13:30:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QMO5t-00073h-6x for qemu-devel@nongnu.org; Tue, 17 May 2011 13:30:09 -0400 Received: from mx1.redhat.com ([209.132.183.28]:37217) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QMO5s-00070i-W6 for qemu-devel@nongnu.org; Tue, 17 May 2011 13:30:05 -0400 Message-ID: <4DD2B151.20202@redhat.com> Date: Tue, 17 May 2011 19:33:05 +0200 From: Hans de Goede MIME-Version: 1.0 References: <1305575782-31766-1-git-send-email-kraxel@redhat.com> <1305575782-31766-19-git-send-email-kraxel@redhat.com> <4DD1E1DD.3060605@cisco.com> <4DD221AB.7070009@redhat.com> <4DD26D45.3070309@cisco.com> <4DD27D9D.1050109@cisco.com> <4DD28E0A.2050808@redhat.com> In-Reply-To: <4DD28E0A.2050808@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 18/18] usb: add ehci adapter List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org, David Ahern Hi, On 05/17/2011 05:02 PM, Gerd Hoffmann wrote: > Hi, > >> (And by the way, where are the focused patches for each, especially the >> last one - nuking the 8kHz code? > > It's squashed in, like everything else. > >> We know that it worked on linux and >> that printers, scanners and storage devices worked ok (mostly). > > 8 kHz is insane. > > I looked closely while trying to make 8 kHz a runtime option instead of a compile time option, then decided to drop it altogether as it is totally pointless. qemu simply can't handle that wakeup rate. It maxed out at ~3 kHz wakeups in my tests. And it burns tons of CPU time. > > I also don't see what it would buy us. We can wakeup with 1 kHz rate (maybe even lower), then emulate 8 (or more) microframes each time. > Agreed, I had a hack in my local tree (which I dropped when preparing things for Gerd to pull) which lowered the wakeup rate for UHCI to 200 and then process 5 frames at a time, this worked fine, including redirection of real usb 1 devices, including usb 1 webcam and audio devices. I would actually like to discuss making the wakeup rate for the UHCI controller lower, maybe together with some mechanism for (emulated) input devices to force a wake-up sooner, so as to not add 4 ms of input latency. Regards, Hans