Date: Wed, 03 Apr 2002 16:58:14 -0500 From: Chris Hanson <[EMAIL PROTECTED]>
I've been doing some more exploration and have found that the performance problem I've been seeing seems to have to do with the way the hardware is initialized. I'm currently using 2.4.18 with the RML preemption patch, and if I boot right into this I get the slow performance. If instead I boot into a fairly vanilla 2.4.17 kernel, then reboot into the 2.4.18+preempt kernel, I get fast performance. I'm running tests right now to narrow this down and figure out if it's 2.4.18 or the preempt patch that's causing the trouble. But if this sounds familiar to anyone, please holler. I've done some more tests, and here are the results. All of these tests were performed on an HP OmniBook 500 laptop, which has an "Intel Corp. 82371AB PIIX4 USB (rev 01)" controller, and runs Debian unstable. In all cases I've used the UHCI ALT (JE) driver. In all cases I was communicating through usbdevfs to a Creative NOMAD II MG MP3 player. I tried several different kernels, including vanilla 2.4.17, vanilla 2.4.18 (with and without USB debug enabled), and 2.4.18 with the preemption patch (preempt-kernel-rml-2.4.18-1.patch). The results were, well, strange. * After doing a cold boot from power off, all kernels consistently behaved the same, providing slow transfer rates of about 55 kB/s. * After rebooting from 2.4.17 to 2.4.18, or from 2.4.18 to 2.4.17, performance usually increased to about 330 kB/s (530 kB/s for large bulk transfers). But not always; sometimes additional reboots were required. This result is independent of the preemption patch and USB debug support. Also, I see no visible differences in the USB debug output between slow and fast states; in all cases the device is reported as a 12 Mb/s device. * Doing a cold boot into 2.4.17 and rebooting to 2.4.17 did not affect performance; it was slow both before and after the reboot. Likewise for 2.4.18, independent of the preemption patch. I don't know how to interpret this. I'm going to do some more tests using the other UHCI driver and see what happens. But I've been avoiding that driver on Greg's advice due to problems communicating with my Visor. My knowledge of the USB subsystem is sketchy at best. But I'd like to figure out what is going on and get it fixed, if possible. Any help you can offer would be appreciated. Chris _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
