From: Jouni Malinen <j@w1.fi>
To: Kalle Valo <kvalo@adurom.com>
Cc: Mohammed Shafi Shajakhan <mshajakhan@atheros.com>,
linville@tuxdriver.com, linux-wireless@vger.kernel.org,
lrodriguez@atheros.com, Jouni Malinen <Jouni.Malinen@atheros.com>
Subject: Re: [PATCH] Revert "ath9k: Parse DTIM period from mac80211"
Date: Sun, 2 Jan 2011 10:53:00 +0200 [thread overview]
Message-ID: <20110102085300.GA14217@jm.kir.nu> (raw)
In-Reply-To: <871v4xgdfp.fsf@purkki.adurom.net>
On Sat, Jan 01, 2011 at 11:50:50AM +0200, Kalle Valo wrote:
> Mohammed Shafi Shajakhan <mshajakhan@atheros.com> writes:
> > * Preventing association with broken AP's
>
> How can different dtim value cause problems with association? Power
> save should not be even enabled during association. Or do you mean
> there are problems after association, for example during eap
> negotation?
It is not the DTIM value, it is the part of having to receive a Beacon
frame before even trying to associate. This is very much a corner case,
but well, that behavior did change with the commit.
> > * Adds latency in roaming
>
> We should try to solve this problem differently than hardcoding dtim.
> There are other ways to trigger roaming than just following beacons.
> And if there's no data, there's no need to roam either.
This is about the part of waiting for Beacon frame before trying to
associate, not about hardcoding DTIM for any other purpose.
> > So its better to always use the safe value of '1' for dtim period
>
> By hardcoding dtim you increase the power consumption in the case when
> there is no data traffic, so it's not definitely better in all cases.
>
> I would prefer to fix the real issues instead of hardcoding dtim. And
> if it's really essential to hardcode it now, please add a big fat
> warning indicating that this is a temporary solution and should be
> fixed properly without hardcoding anything.
The real issue (as far as I can tell) was that ath9k was changed to
require mac80211 to get it DTIM period before association. I'm not aware
of any need for that with ath9k. It should have no problems updating PS
parameters after association and as such, should not require mac80211 to
figure DTIM period out before being able to associate. This change is
not about hardcoding DTIM period; it is about removing unneeded change
that added extra latency without any real gain.
--
Jouni Malinen PGP id EFC895FA
next prev parent reply other threads:[~2011-01-02 8:53 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-30 6:48 [PATCH] Revert "ath9k: Parse DTIM period from mac80211" Mohammed Shafi Shajakhan
2011-01-01 9:50 ` Kalle Valo
2011-01-02 8:53 ` Jouni Malinen [this message]
2011-01-03 7:29 ` Mohammed Shafi
2011-01-03 21:25 ` 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=20110102085300.GA14217@jm.kir.nu \
--to=j@w1.fi \
--cc=Jouni.Malinen@atheros.com \
--cc=kvalo@adurom.com \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=lrodriguez@atheros.com \
--cc=mshajakhan@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 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).