From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JCGQU-0008Bv-2G for qemu-devel@nongnu.org; Tue, 08 Jan 2008 10:31:38 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JCGQP-000892-3a for qemu-devel@nongnu.org; Tue, 08 Jan 2008 10:31:37 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JCGQO-00088r-R1 for qemu-devel@nongnu.org; Tue, 08 Jan 2008 10:31:32 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JCGQO-0003hW-D1 for qemu-devel@nongnu.org; Tue, 08 Jan 2008 10:31:32 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation Date: Tue, 8 Jan 2008 15:31:23 +0000 References: <64F9B87B6B770947A9F8391472E0321610478FD1@ehost011-8.exch011.intermedia.net> <200801080130.04161.paul@codesourcery.com> <1199781789.4421.7.camel@localhost.localdomain> In-Reply-To: <1199781789.4421.7.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200801081531.27719.paul@codesourcery.com> 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, dor.laor@qumranet.com Cc: Arnon Gilboa On Tuesday 08 January 2008, Dor Laor wrote: > On Tue, 2008-01-08 at 01:30 +0000, Paul Brook wrote: > > > -The host kernel was configured with dynamic tick & hi-res timers, to > > > allow the desired timer resolution. USB 2.0 microframe is 125usec. > > It still works even without accurate timing demands. > Only isochronous mode will have problems and it is not yet supported for > ehci. It could also cause problems for periodic interrupt transfers. It's not uncommon for linux hosts to have a minimum timer period of 10ms (100Hz). This means the periodic list will be traversed 80x slower than it should, so a typical for a mouse or tablet with a 10ms poll interval will only be polled every 800ms. 800ms lag on a mouse is unacceptable. The existing USB hosts have similar issues. However the problem is an order of magnitude less severe, so isn't noticeable under normal circumstances. > > Requiring a 8kHz timer is a non-starter. > > > > The 100kHz "retry" timer is even more bogus. > > > > Qemu isn't capable of this kind of realtime response. You need to figure > > out an implementation that doesn't require extremely fine grained timers. > > In paractice you're unlikely to get better than 10ms timer resolution, > > and 100ms latency isn't that uncommon. > > > > Paul > > Latest Linux host compiled HR_TIMER and DYN_TICK can give pretty good > accuracy, surely it can provide 1khz and probably even 8khz Only if the host is lightly loaded. qemu tends to use a lot of CPU, so scheduler heuristics will tend to give it a low priority. c.f. an mp3 player that uses a small amount of CPU, so the scheduler will try hard to provide prompt signal delivery. Paul