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