On 05/17/11 09:02, Gerd Hoffmann wrote: > > Hi, > >> (And by the way, where are the focused patches for each, especially the >> last one - nuking the 8kHz code? > > It's squashed in, like everything else. > >> We know that it worked on linux and >> that printers, scanners and storage devices worked ok (mostly). > > 8 kHz is insane. > > I looked closely while trying to make 8 kHz a runtime option instead of > a compile time option, then decided to drop it altogether as it is > totally pointless. qemu simply can't handle that wakeup rate. It maxed > out at ~3 kHz wakeups in my tests. And it burns tons of CPU time.
Our mileage varies. While CPU usage was high (30%'ish) when the device was in use, the controller was stopped when devices are not accessed. All in all my laptop was billowing smoke while using it. > > I also don't see what it would buy us. We can wakeup with 1 kHz rate > (maybe even lower), then emulate 8 (or more) microframes each time. How much time have you spent looking at isochronous devices (web cams, audio streaming, iphones)? Your positive that the 8k code will not be needed for it? My point is that you prematurely nuked code that is controlled by a define which allows you to try both paths. David > > Throughput issues (guess this is the reason to try 8kHz wakeups) need to > be addressed by modeling data pipes in the usb system instead of playing > ping-pong between EHCI and USB device emulation for each single usb > packet, at 8 kHz. > > I see the ehci merge just as very first step. USB 2.0 (and 3.0) support > in qemu still has a loooooooong way to go. > > cheers, > Gerd >
