Linux wireless drivers development
 help / color / mirror / Atom feed
From: Andrea Merello <andreamrl@tiscali.it>
To: Florian Zumbiehl <florz@florz.de>
Cc: Larry Finger <Larry.Finger@lwfinger.net>,
	herton@mandriva.com.br, htl10@users.sourceforge.net,
	linux-wireless@vger.kernel.org
Subject: Re: Power consumption of RTL8187 (driver)/recommendations for low-power USB 802.11 adapter?
Date: Sat, 19 Dec 2009 11:30:09 +0100	[thread overview]
Message-ID: <c68f135e0912190230o566b3c3dk9be3038b0602cac5@mail.gmail.com> (raw)
In-Reply-To: <20091219011306.GG2512@florz.florz.dyndns.org>

>> 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 ... ;-)

On the AP you might set the beacon interval lower. And also, I'm not
sure if the rtl8187 driver configure the BSSID register so that once
you are associated to the network the card will filter all packets
from other APs, but in case it does not you can try to set your AP on
a channel where no other AP are working, otherwise other APs beacons
will be reiceved.


> 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?!

Hmm.. I think I know not enough about C3 state rules.
I think the rtl8187 does not use timers.
The only difference is that the interrupt is raised by the (PCI) USB
controller, then it forwards things to the USB layer, then it calls a
callback on the rtl8187 driver, and then it passes to the mac80211
layer. So the problem might be not the interrupt itself but the amount
of work to do..


> 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.

Hmm.. Well.. I guess that effectively a USB softmac card on a slow
computer might produce a noticeable overhead, even if I never tried
before..

>> 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?

I know that intel ipw2200 and the older ipw2100 should be fullmac.
Some prism, as you said are fullmac, and even some Marvell (for sure
some PCI, I don't know about USB) are fullmac.

There might be other but I don't know for sure..

  reply	other threads:[~2009-12-19 10:30 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-18 18:02 Power consumption of RTL8187 (driver)/recommendations for low-power USB 802.11 adapter? Florian Zumbiehl
2009-12-18 18:20 ` Larry Finger
2009-12-18 18:59   ` Florian Zumbiehl
2009-12-18 23:28     ` Larry Finger
2009-12-19  0:15       ` Andrea Merello
2009-12-19  1:13         ` Florian Zumbiehl
2009-12-19 10:30           ` Andrea Merello [this message]
2009-12-19 15:32             ` Hin-Tak Leung
2009-12-19 18:44             ` Florian Zumbiehl
2009-12-19 23:31               ` Hin-Tak Leung
2009-12-21 21:27                 ` Florian Zumbiehl
2009-12-20 18:43         ` Kalle Valo
2009-12-19  0:37       ` Florian Zumbiehl
2009-12-19 10:19         ` Andrea Merello

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c68f135e0912190230o566b3c3dk9be3038b0602cac5@mail.gmail.com \
    --to=andreamrl@tiscali.it \
    --cc=Larry.Finger@lwfinger.net \
    --cc=florz@florz.de \
    --cc=herton@mandriva.com.br \
    --cc=htl10@users.sourceforge.net \
    --cc=linux-wireless@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox