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
