linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kalle Valo <kalle.valo@iki.fi>
To: Tomas Winkler <tomasw@gmail.com>
Cc: johannes@sipsolutions.net, vivek.natraj@gmail.com,
	linux-wireless@vger.kernel.org
Subject: Re: [RFC PATCH v2 2/2] mac80211: use ps-poll when dynamic power save  mode is disabled
Date: Wed, 28 Jan 2009 10:39:21 +0200	[thread overview]
Message-ID: <874ozj964m.fsf@litku.valot.fi> (raw)
In-Reply-To: <1ba2fa240901231528m21f13c1m43721f1d673e7cc7@mail.gmail.com> (Tomas Winkler's message of "Sat\, 24 Jan 2009 01\:28\:43 +0200")

Tomas Winkler <tomasw@gmail.com> writes:

> On Thu, Jan 22, 2009 at 1:45 PM, Kalle Valo <kalle.valo@nokia.com> wrote:
>> When a directed tim bit is set, mac80211 currently disables power save
>> ands sends a null frame to the AP. But if dynamic power save is
>> disabled, mac80211 will not enable power save ever gain.
>
> Why not?

Because of a bug.

>> Fix this by
>> adding ps-poll functionality to mac80211. When a directed tim bit is
>> set, mac80211 sends a ps-poll frame to the AP and checks for the more
>> data bit in the returned data frames.
>
> Still have to see the implementation but this sounds strange.

Please be more specific, I don't understand what part you think is
strange. This is specified in the spec, see chapter 11.2.

>> Using ps-poll is slower than waking up with null frame, but it's saves more
>> power in cases where the traffic is low. Userspace can control if either
>> ps-poll or null wakeup method is used by enabling and disabling dynamic
>> power save.
>
> Do you have numbers how much power you save?

Unfortunately not yet.

> With PS-Poll you must stay awak longer not saying that issueing TX
> (PS-poll) also consume power.Ususally TXing has higher power
> consumption then RX. Instead of tx(null PM=0) rx tx(ack)...rx
> tx(ack) tx(null PM=1) you have now tx(ps-poll) rx tx (ack)
> tx(ps-poll) rx tx(ack). So if the AP holds more then 3 packetes PS
> poll will consume more power in this very simplified computation.

Let's take the null frame approach:

1. notice tim bit set
2. send null frame (pm=0)
3. receive data frames
4. wait for all buffered data frames
5. send null frame (pm=1)

How do you know when the station has received all buffered data frames
from the AP (item 4 above)? By waiting a certain period after the last
received data frame? If that timeout is too short, we will get packet
loss, which is not good. If the timeout is too long, we waste too much
power.

With ps-poll we don't have to set any timeouts, the station can go to
sleep immeadiately after receiving a data frame with moredata bit not
set. So I see a clear advantage in certain cases where the data
troughput is very low and maximum power savings is desired. For
example when the device is idle on the table, display turned off and
only irc/jabber session is running in the background.

And remember that userspace can control this with the power timeout
setting. My recommendation would be to use this only when the device
is idle and display is turned off.

> Do you measure power consumption on of the NIC or the whole system?

Usually I measure just the whole system. I can measure the nic, but
that's very time consuming.

-- 
Kalle Valo

  reply	other threads:[~2009-01-28  8:39 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-22 11:45 [RFC PATCH v2 0/2] mac80211: ps-poll implementation Kalle Valo
2009-01-22 11:45 ` [RFC PATCH v2 1/2] mac80211: remove multicast check from check_tim() Kalle Valo
2009-01-28 14:59   ` Vivek Natarajan
2009-01-28 16:06     ` Kalle Valo
2009-01-22 11:45 ` [RFC PATCH v2 2/2] mac80211: use ps-poll when dynamic power save mode is disabled Kalle Valo
2009-01-22 17:02   ` Johannes Berg
2009-01-28 16:49     ` Kalle Valo
2009-01-28 18:52       ` Johannes Berg
2009-01-29 18:15         ` Kalle Valo
2009-01-29 18:32           ` Johannes Berg
2009-01-29 20:19             ` Kalle Valo
2009-01-23 23:28   ` Tomas Winkler
2009-01-28  8:39     ` Kalle Valo [this message]
2009-01-28 11:46       ` Tomas Winkler
2009-01-28 12:33         ` Kalle Valo
2009-01-28 13:00         ` Johannes Berg
2009-01-28 13:26           ` Tomas Winkler
2009-01-28 13:36             ` Johannes Berg
2009-01-22 13:00 ` [RFC PATCH v2 0/2] mac80211: ps-poll implementation Johannes Berg
2009-01-23  9:31   ` Kalle Valo
2009-01-23 22:11     ` Johannes Berg
2009-01-28 16:40       ` Kalle Valo

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=874ozj964m.fsf@litku.valot.fi \
    --to=kalle.valo@iki.fi \
    --cc=johannes@sipsolutions.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=tomasw@gmail.com \
    --cc=vivek.natraj@gmail.com \
    /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;
as well as URLs for NNTP newsgroup(s).