This patch ensures fair beacon distribution in IBSS mode
by configuring proper CWmin based on slot time.
Signed-off-by: Rajkumar Manoharan <[email protected]>
---
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)) {
--
1.7.3
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 <[email protected]>
> ---
> 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?
bruno
>> > - 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?
Hi Bruno,
Sorry for long gap. somehow I missed your mail. During our Interop Testing, we
observed that ath9k based cards utilized the channel more frequently that others.
To ensure fair beacon distribution, BE queue parameters were set to beacon queue.
But still I couldn't find specific WMM parameters for beacon queue except
hostap.conf which stats that
tx_queue_beacon_aifs=2
tx_queue_beacon_cwmin=3
tx_queue_beacon_cwmax=7
tx_queue_beacon_burst=1.5
With these parameter we need to test again :) Any comments are welcome.
- Rajkumar
On Thu, Nov 04, 2010 at 05:11:18PM +0530, Rajkumar Manoharan wrote:
> Sorry for long gap. somehow I missed your mail. During our Interop Testing, we
> observed that ath9k based cards utilized the channel more frequently that others.
> To ensure fair beacon distribution, BE queue parameters were set to beacon queue.
Looking at interop testing results may end up being the most realistic
way of getting this working properly regardless of what the standard
says..
> But still I couldn't find specific WMM parameters for beacon queue except
> hostap.conf which stats that
>
> tx_queue_beacon_aifs=2
> tx_queue_beacon_cwmin=3
> tx_queue_beacon_cwmax=7
> tx_queue_beacon_burst=1.5
Thanks for bringing those up.. I did not realize that the extra TX queue
parameters were still included in hostapd.conf (well, they are not
anymore.. ;-). Anyway, these were used in infrastructure BSS (i.e., by
an AP), not in an IBSS. IBSS is governed by special rules in IEEE Std
802.11-2007, 11.1.2.2 like Bruno already pointed out. While management
frames in general use AC_VO (until 802.11ae comes to play..), IBSS
Beacon distribution is specified to follow special rules: "Calculate a
random delay uniformly distributed in the range between
zero and twice aCWmin x aSlotTime." where aCWmin depends on the
used PHY, not some configurable AC-specific CWmin value.
--
Jouni Malinen PGP id EFC895FA
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 <[email protected]>
> > ---
> >
> > 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