Re: Power consumption of RTL8187 (driver)/recommendations for low-power USB 802.11 adapter?

[Florian Zumbiehl <florz@florz.de>]

Hi,

[...]
> As someone told before this management traffic is for examples beacons.

IC - I hadn't thought that softmac really meant basically "radio only" =:-)

> Probably your prism2 card was a so called "fullmac" card. That menas
> that all this management stuff can be done on the wifi card without
> generating load on the host CPU.

Yeah, it is.

> One thing I can say is that the ieee 802.11 protocol allows certains
> power save functionalities but, provided that mac80211 / rtl8187
> driver support it (and I'm really not sure), this will probably only
> reduces power consumption on the USB, not on the host processor.

That certainly would be nice, too, but it seems that most of the power
consumption really comes from the host processor. I guess I should
measure the current going through the USB connetion ...

> Well, it may be interesting to do a serious analisys about how much
> power is drained by the card when it is up and in RX, when the
> mac80211 sends probes, and how much is related to the CPU, however,
> because you estimated that the power drain increase is too much for
> being directly related to the usb stuff, I think is really possible
> that the big problem is related to beacons.

I'll play around with AP settings a bit and report back to you.
If you can think of any particular useful tests I could do, please
let me know, I'll see what I can do.

But yeah - even if the device draws more than the allowed 500 mA,
I hope very much that it doesn't draw anywhere close to 3 A ... ;-)

[...]
> This means that, IMHO, there is no way to avoid the CPU work on
> rtl8187 when you are connected to a network (unless the network AP is
> yours and you reduce beacon interval as someone suggested). Maybe you
> can force some powersave mode on the CPU, by scaling the cpu clock
> frequency, avoiding taht some "ondemand" policy can rise the clock
> when the CPU is loaded (I doubt beacons processing is enough to
> trigger this), but If you tracked down that interrupts are the causes
> of the CPU don't entering C3 state, I _think_ you can't do much..

I would assume that it's some timers you are using? As I understand it,
other interrupts (which cannot really be predicted) don't prevent
the power management code from switching the CPU into deep sleep
modes?!

It's only a PIII, which is too slow with frequency changes for
the ondemand governor, and the speedstep driver also causes other
yet-unresolved problems (audio stuttering) when loaded.
So it's not really a solution in this case, even though you are
right that the actual CPU cycles used would suggest that newer
processors should be able to stay at their minimum frequency with
the ondemand governor.

> So far If you are looking for a card that make you save power, I
> suggest you to get a fullmac one.

Any suggestions as to how to recognize those? Or even a recommendation
for a specific device/chipset?

Florian