On Wed, 3 Oct 2007, Alan Jenkins wrote: > > One other thing: EHCI transfers data 40 times faster than UHCI. All > > else being equal, you would be justified in expecting it to generate 40 > > times as many interrupts per second. The fact that it doesn't > > indicates something -- perhaps that the real bottleneck isn't in these > > controllers at all but somewhere else in the system. > > > This is on an idle system (for "desktop linux" values of idle). I'm not > transferring data at maximum bus speed; in fact I'm not doing anything > as a user that requires network access. So I wasn't particularly > expecting more interrupts on ehci.
Even though you're not doing anything that requires network access, as long as the network interface is enabled it needs to respond to incoming or broadcast packets. The adapter driver may even poll the USB device; I don't know how it works. > > ehci doesn't poll at all under normal circumstances, but it does use a > > timer to disable the async schedule. As I mentioned above, uhci polls > > at 4/second. > > > > Alan Stern > So if I want to find out why ehci causes more wakeups on an idle system > than uhci, I need to break down the ehci_watchdog timer into its > component uses. Yes. Probably the important one for you is the async-schedule-disable timeout. It will fire some milliseconds after all bulk and control transfers are complete, telling ehci-hcd that it can turn off the async schedule. > Um. So the ehci hardware is generating 10 interrupts a second on my > idle desktop. Remember, even though your desktop is idle, that doesn't mean the network is idle. > Each ehci interrupt is associated with DMA activity. The > driver sets timeouts to check whether DMA has finished and can be > disabled. Assuming that DMA activity happens at regular intervals, it > wouldn't make sense for the DMA activity _timeouts_ to happen any less > frequently. So I also get 10 timeouts per second to go with the 10 > interrupts. That accounts for the wakeups I'm seeing on powertop. That sounds about right. > So that's it then. autosuspend isn't supported for my device yet. I > assume theres no way I could get the ehci hardware interrupts lower than > 10 Hz in this case, and that it doesn't make sense to try and avoid the > watchdog timeout. Try doing an ifconfig down on the network interface and see what happens. Or since you say everything is idle and you aren't using the network anyway, simply unplug the wireless adapter. Alan Stern ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Linux-usb-users@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-users
