Re: Prevent auto scan in wireless devices

On Sun, 2009-02-01 at 12:58 +0000, Marc Herbert wrote:
> Dan Williams <dcbw redhat com> writes:
> > On Tue, 2009-01-13 at 17:45 -0300, Aloisio Almeida wrote:
> >
> >  Can you get some quantifiable
> > power measurements on whether scanning (for both active and passive)
> > *really* make a large difference here?  Chips are good enough these days
> > that scanning doesn't really draw more power than having the chip awake.
> Actually I found this discussion in Google while trying to understand
> why powertop was going crazy since I finally (tried to) move from
> ifupdown to NetworkManager.
> - ifdown eth1
>    => my CPU is in C4 state for 99.7 % of the time.
> - NetworkManager.DisableWireless()
>   => my CPU is now in C4 state for only 96% of the time, because my wireless
>      driver throws 90 interrupts per second, because it keeps scanning.

So when you disable wireless in NetworkManager, what state is the
wireless driver in?  What does 'iwconfig' and 'ifconfig' say?  Can you
compare that output with the output from "ifdown eth1"?

When wireless is disabled in NetworkManager, it should not be touching
the card, and will set the card down just the same way 'ifconfig eth1
down' does.  Thus, the card/driver should not be doing *anything* with
the hardware, and should put the hardware into a low power state similar
to rfkill.

Can you get the difference with iwconfig/ifconfig between NM's disable
wireless state and the 'ifdown' state for me?  I'd like to figure out
what's going on here.

> I am not saying the problem belongs to NetworkManager. But as a plain
> stupid luser who is not interested in who is responsible for what, the
> move to NetworkManager resulted in a power regression. And by the way
> it took me some significant effort to finally understand what was
> going on.
> You could answer that my wireless driver is buggy to throw so many
> interruptions. Maybe. Sorry, but this is the only driver I (and a few
> other millions of users) have. We would really appreciate if you could
> avoid exposing a bug who was prefectly hidden before.

I can't fix drivers that aren't open, and I'm not going to put lots of
unmaintainable hacks into NetworkManager just to work around stupid
drivers.  If I did that, there would be a huge pile of them already, and
that's certainly no way to run a software project.  Hopefully your
driver isn't stupid and isn't the problem, and it's something we can
easily solve.


> You could answer that I should use an alternative tool to power down
> my interface, like for instance a hardware switch. First not every one
> has a hardware switch. Then a hardware switch does not run my polite
> dispatcher.d scripts which clean-up remote resources. And finally I
> would appreciate if you could make sure this "alternative power
> management tool", whichever it is, is available and working well
> before removing a feature that was working fine in ifupdown.
> Sorry for taking the "write-only" stance of a stupid and ignorant
> luser; I did it because I am afraid they do not pop up so often deep
> down in here.
> PS: NetworkManager is very promising and an order of magnitude more
> user-friendly than ifupdown. Keep up the good work.
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]