From: Bruno Randolf <br1@einfach.org>
To: Rajkumar Manoharan <rmanoharan@atheros.com>, lrodriguez@atheros.com
Cc: linville@tuxdriver.com, linux-wireless@vger.kernel.org,
Felix Fietkau <nbd@openwrt.org>
Subject: Re: [PATCH v2] ath9k_htc: Fix beacon distribution in IBSS mode
Date: Thu, 4 Nov 2010 19:05:26 +0900 [thread overview]
Message-ID: <201011041905.26464.br1@einfach.org> (raw)
In-Reply-To: <201009271018.42232.br1@einfach.org>
On Mon September 27 2010 10:18:42 Bruno Randolf wrote:
> On Tue September 21 2010 16:28:09 Rajkumar Manoharan wrote:
> > This patch ensures fair beacon distribution in IBSS mode
> > by configuring proper CWmin based on slot time.
> >
> > Signed-off-by: Rajkumar Manoharan <rmanoharan@atheros.com>
> > ---
> >
> > drivers/net/wireless/ath/ath9k/htc_drv_beacon.c | 9 ++++++++-
> > 1 files changed, 8 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
> > b/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c index bd1506e..1b72aa4
> > 100644
> > --- a/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
> > +++ b/drivers/net/wireless/ath/ath9k/htc_drv_beacon.c
> > @@ -235,7 +235,14 @@ void ath9k_htc_beaconq_config(struct ath9k_htc_priv
> > *priv) ath9k_hw_get_txq_props(ah, qnum, &qi_be);
> >
> > qi.tqi_aifs = qi_be.tqi_aifs;
> >
> > - qi.tqi_cwmin = 4*qi_be.tqi_cwmin;
> > + /* For WIFI Beacon Distribution
> > + * Long slot time : 2x cwmin
> > + * Short slot time : 4x cwmin
> > + */
> > + if (ah->slottime == ATH9K_SLOT_TIME_20)
> > + qi.tqi_cwmin = 2*qi_be.tqi_cwmin;
> > + else
> > + qi.tqi_cwmin = 4*qi_be.tqi_cwmin;
> >
> > qi.tqi_cwmax = qi_be.tqi_cwmax;
> >
> > if (!ath9k_hw_set_txq_props(ah, priv->beaconq, &qi)) {
>
> i am wondering - how does this relate to what i read in IEEE802.11-2007:
>
> 11.1.2.2 Beacon generation in an IBSS
>
> b) Calculate a random delay uniformly distributed in the range between
> zero and twice aCWmin × aSlotTime,
>
> wouldn't that mean that cwmin for the beacon queue should be 0 and cwmax
> should be 2x cwmin * slot time?
>
> if the beacon queue cwmin is higher than the best effort queue, it would
> mean that the best effort queue gets precedence over beacon transmissions.
> but we want beacons to get sent out in any case.
>
> also, what is the rationale behind using the best effort queue as a
> reference for cwmin/cwmax?
I'm following up my own message since I just stumbled across that paragraph,
which IMHO would imply that the beacon queue should be based on AC_VO instead
of AC_BE, if anything.
[9.2.4.2 HCF contention-based channel access (EDCA):
Management frames shall be sent using the access category AC_VO
without being restricted by admission control procedures. A QoS STA shall also
send management frames using the access category AC_VO before associating with
any BSS, even if there is no QoS facility available in that BSS.]
Also I still doubt that 4*qi_be.tqi_cwmin is correct concerning the standard
paragraph which i quoted before. Did I miss something?
Bruno
next prev parent reply other threads:[~2010-11-04 10:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-21 7:28 [PATCH v2] ath9k_htc: Fix beacon distribution in IBSS mode Rajkumar Manoharan
2010-09-27 1:18 ` Bruno Randolf
2010-11-04 10:05 ` Bruno Randolf [this message]
2010-11-04 11:41 ` Rajkumar Manoharan
2010-11-05 0:05 ` Jouni Malinen
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=201011041905.26464.br1@einfach.org \
--to=br1@einfach.org \
--cc=linux-wireless@vger.kernel.org \
--cc=linville@tuxdriver.com \
--cc=lrodriguez@atheros.com \
--cc=nbd@openwrt.org \
--cc=rmanoharan@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