[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation

From: Paul Brook
Subject: Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
Date: Tue, 8 Jan 2008 15:31:23 +0000
User-agent: KMail/1.9.7

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]