Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
On Tue, 2008-01-08 at 01:30 +, 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. 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 Dor
RE: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
The WinXP guest seems to work fine with the timer resolution, accuracy and latency of qemu. The problem with linux guests might be related to this issue. I will test the ehci emulation without the specified kernel config and see how can we handle timing issues in a more qemu-oriented way. Any tip? Arnon -Original Message- From: Paul Brook [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 08, 2008 3:30 AM To: qemu-devel@nongnu.org Cc: Arnon Gilboa; KVM; Roni Luxenberg Subject: Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation -The host kernel was configured with dynamic tick hi-res timers, to allow the desired timer resolution. USB 2.0 microframe is 125usec. 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
Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
On Tuesday 08 January 2008, Dor Laor wrote: On Tue, 2008-01-08 at 01:30 +, 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
Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
Paul Brook wrote: On Tuesday 08 January 2008, Dor Laor wrote: On Tue, 2008-01-08 at 01:30 +, 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. Surely qemu should read the time and adjust? For example, a 1000Hz guest running on a 100Hz host will see a 10x slowdown in real time. -- error compiling committee.c: too many arguments to function
Re: [Qemu-devel] [PATCH] USB 2.0 EHCI emulation
-The host kernel was configured with dynamic tick hi-res timers, to allow the desired timer resolution. USB 2.0 microframe is 125usec. 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
