From: Johannes Berg <johannes@sipsolutions.net>
To: "Luis R. Rodriguez" <lrodriguez@atheros.com>
Cc: Jouni Malinen <j@w1.fi>,
linux-wireless@vger.kernel.org, Kalle Valo <kvalo@adurom.com>,
Amod Bodas <Amod.Bodas@atheros.com>
Subject: Re: [RFT] mac80211: fix broadcast/multicast data drop on scan
Date: Fri, 27 Aug 2010 17:43:19 +0200 [thread overview]
Message-ID: <1282923799.4377.14.camel@jlt3.sipsolutions.net> (raw)
In-Reply-To: <AANLkTi=qWjhwo50hg8HB1wtsyUizAi55SEK9EW0Udckv@mail.gmail.com>
On Fri, 2010-08-27 at 08:40 -0700, Luis R. Rodriguez wrote:
> On Fri, Aug 27, 2010 at 8:37 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Fri, 2010-08-27 at 08:28 -0700, Luis R. Rodriguez wrote:
> >
> >> Indeed... I do not see where we keep track of the DTIM count and was
> >> afraid this was not sufficient. I had not thought about the last
> >> received multicast / broadcast frame, that will require some more
> >> work. But I also noticed even ieee80211_recalc_ps() does not take this
> >> into account when computing the max_sleep_period ieee80211_enable_ps()
> >> for dynamic power save, it only considers the DTIM period. We send the
> >> nullfunc frame for dynamic power save and it does not seem we take
> >> into consideration the DTIM count and last RX's broadcast / multicast
> >> data prior to sending the nullfunc to go into power save. So it seems
> >> to me dynamic power save would also loses broadcast / multicast data
> >> frames.
> >
> > No, the max sleep period is just a helper variable for device
> > implementation of sleep -- the actual alignment of it with DTIM beacons
> > etc. has to be done by the device. Therefore, it isn't so :-)
>
> I noticed the comment on the PS documentation that the reason for this
> is that mac80211 is too slow, is that right?
Well, there's no way we can reliably wake up exactly before a beacon by
implementing that in software, hard real-time hasn't been achieved in
Linux yet :-)
johannes
next prev parent reply other threads:[~2010-08-27 15:43 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-27 5:38 [RFT] mac80211: fix broadcast/multicast data drop on scan Luis R. Rodriguez
2010-08-27 9:06 ` Jouni Malinen
2010-08-27 15:28 ` Luis R. Rodriguez
2010-08-27 15:37 ` Johannes Berg
2010-08-27 15:40 ` Luis R. Rodriguez
2010-08-27 15:43 ` Johannes Berg [this message]
2010-08-27 15:48 ` Luis R. Rodriguez
2010-08-27 15:51 ` Johannes Berg
2010-08-27 15:55 ` Luis R. Rodriguez
2010-08-27 15:58 ` Johannes Berg
2010-08-27 18:30 ` Luis R. Rodriguez
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=1282923799.4377.14.camel@jlt3.sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=Amod.Bodas@atheros.com \
--cc=j@w1.fi \
--cc=kvalo@adurom.com \
--cc=linux-wireless@vger.kernel.org \
--cc=lrodriguez@atheros.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.