[Make-wifi-fast] Fwd: [Battlemesh] BSS load element patch

[Make-wifi-fast] Fwd: [Battlemesh] BSS load element patch

[Dave Taht]

[-- Attachment #1.1.1: Type: text/plain, Size: 1045 bytes --]

a thought
---------- Forwarded message ----------
From: Arthur LENA <arthur@lena.im>
Date: Mon, Aug 3, 2015 at 9:07 PM
Subject: [Battlemesh] BSS load element patch
To: battlemesh@ml.ninux.org


Hi all!

Attached the patch adding the BSS Load IE to the beacon sent by the ath9k
driver (specification can be found @ IEEE802.11-2012 §8.4.2.30). It fills
the channel utilization field (based on cycles counters read out of the
chipsets) and the station count field. This patch applies successfully to
the compat-wireless package in the OpenWRT build environment (trunk r45674)
and was tested on the WDR4300. All comments are welcome!!



Cheers
Arthur

_______________________________________________
Battlemesh mailing list
Battlemesh@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/battlemesh




-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

[-- Attachment #1.1.2: Type: text/html, Size: 1926 bytes --]

[-- Attachment #1.2: Type: image/png, Size: 28589 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: qbss_ath9k.patch --]
[-- Type: text/x-patch; charset=US-ASCII; name="qbss_ath9k.patch", Size: 4575 bytes --]

commit 7e1e7ca17d3159b562bcc59d7bc27fabb1f50d73
Author: Arthur Léna <Lena@ftw.at>
Date:   Tue May 12 19:39:48 2015 +0200

    ath9k: add QBSS IE to the beacons
    
    Summary:
    * the QBSS IE is added to the beacons in the ath9k driver.
    * the value of the channel load element is calculated over a fixed
    	period of 50 beacon intervals (i.e., 5 seconds with the
    	default beacon interval).
    * a counter for the number of associated stations has been added
    	for each virtual interface in the ath_vif struct. This allows
    	to fill the station count element of the QBSS IE.

diff --git a/package/kernel/mac80211/patches/940-ath9k_qbss_load_element.patch b/package/kernel/mac80211/patches/940-ath9k_qbss_load_element.patch
new file mode 100644
index 0000000..393ab99
--- /dev/null
+++ b/package/kernel/mac80211/patches/940-ath9k_qbss_load_element.patch
@@ -0,0 +1,109 @@
+--- a/drivers/net/wireless/ath/ath9k/beacon.c
++++ b/drivers/net/wireless/ath/ath9k/beacon.c
+@@ -15,6 +15,7 @@
+  */
+
+ #include <linux/dma-mapping.h>
++#include <linux/kernel.h>
+ #include "ath9k.h"
+
+ #define FUDGE 2
+@@ -109,6 +110,46 @@ static void ath9k_beacon_setup(struct at
+	ath9k_hw_set_txdesc(ah, bf->bf_desc, &info);
+ }
+
++static void ath9k_beacon_add_qbss(struct ath_softc *sc,
++	struct ieee80211_vif *vif, struct sk_buff *skb, int beacon_interval)
++{
++    /* default - 802.11e annex D: dot11ChannelUtilizationBeaconInterval */
++    static const u8 qbss_ie_hdr[] = {
++        WLAN_EID_QBSS_LOAD,             /* type */
++        0x05,                           /* length */
++        0x00, 0x00, 0x00, 0x00, 0x00   /* dummy values */
++    };
++    u8 *hdr;
++    struct ath_hw *ah = sc->sc_ah;
++    struct ath_common *common = ath9k_hw_common(ah);
++	struct ath_vif *avp = (void *)vif->drv_priv;
++    static const u8 QBSS_CU_BEACON_INTERVAL_MAX = 50;
++    static u32 channel_time_busy = 0;
++    static u64 last_channel_time_busy = 0;
++    static u8 qbss_cu_beacon_int = 0;
++    static u8 qbss_channel_load;
++
++    /* get the information out of the survey struct for the current channel */
++    spin_lock_bh(&common->cc_lock);
++
++    if (++qbss_cu_beacon_int == QBSS_CU_BEACON_INTERVAL_MAX) {
++        channel_time_busy = sc->cur_survey->time_busy - last_channel_time_busy;
++        channel_time_busy += ath_update_survey_stats(sc);
++        qbss_channel_load = channel_time_busy * 255 /
++            (beacon_interval * qbss_cu_beacon_int);
++        channel_time_busy = 0;
++        qbss_cu_beacon_int = 0;
++        last_channel_time_busy = sc->cur_survey->time_busy;
++    }
++
++    spin_unlock_bh(&common->cc_lock);
++
++    hdr = skb_put(skb, sizeof(qbss_ie_hdr));
++    memcpy(hdr, qbss_ie_hdr, sizeof(qbss_ie_hdr));
++	*((u16 *) (hdr + 2)) = cpu_to_le16(avp->n_assoc_stations);
++    *(hdr+4) = qbss_channel_load;
++}
++
+ static struct ath_buf *ath9k_beacon_generate(struct ieee80211_hw *hw,
+					     struct ieee80211_vif *vif)
+ {
+@@ -151,6 +192,9 @@ static struct ath_buf *ath9k_beacon_gene
+	if (vif->p2p)
+		ath9k_beacon_add_noa(sc, avp, skb);
+
++    ath9k_beacon_add_qbss(sc, vif, skb,
++        avp->chanctx->beacon.beacon_interval);
++
+	bf->bf_buf_addr = dma_map_single(sc->dev, skb->data,
+					 skb->len, DMA_TO_DEVICE);
+	if (unlikely(dma_mapping_error(sc->dev, bf->bf_buf_addr))) {
+--- a/drivers/net/wireless/ath/ath9k/ath9k.h
++++ b/drivers/net/wireless/ath/ath9k/ath9k.h
+@@ -623,6 +623,8 @@ struct ath_vif {
+	u32 noa_duration;
+	bool periodic_noa;
+	bool oneshot_noa;
++
++	u16 n_assoc_stations;
+ };
+
+ struct ath9k_vif_iter_data {
+--- a/drivers/net/wireless/ath/ath9k/main.c
++++ b/drivers/net/wireless/ath/ath9k/main.c
+@@ -1488,6 +1488,7 @@ static int ath9k_sta_add(struct ieee8021
+	struct ath_softc *sc = hw->priv;
+	struct ath_common *common = ath9k_hw_common(sc->sc_ah);
+	struct ath_node *an = (struct ath_node *) sta->drv_priv;
++	struct ath_vif *avp = (void *)vif->drv_priv;
+	struct ieee80211_key_conf ps_key = { };
+	int key;
+
+@@ -1503,6 +1504,8 @@ static int ath9k_sta_add(struct ieee8021
+		an->key_idx[0] = key;
+	}
+
++	avp->n_assoc_stations++;
++
+	return 0;
+ }
+
+@@ -1527,9 +1530,11 @@ static int ath9k_sta_remove(struct ieee8
+			    struct ieee80211_sta *sta)
+ {
+	struct ath_softc *sc = hw->priv;
++	struct ath_vif *avp = (void *)vif->drv_priv;
+
+	ath9k_del_ps_key(sc, vif, sta);
+	ath_node_detach(sc, sta);
++	avp->n_assoc_stations--;
+
+	return 0;
+ }

[Make-wifi-fast] Fwd: [Battlemesh] BSS load element patch

[Dave Taht]

---------- Forwarded message ----------
From: Paul Fuxjaeger <fuxjaeger@ftw.at>
Date: Fri, Aug 7, 2015 at 11:28 AM
Subject: Re: [Battlemesh] BSS load element patch
To: Battle of the Mesh Mailing List <battlemesh@ml.ninux.org>


On 05.08.15 14:57, Bastian Bittorf wrote:

> Does e.g. a client gets informed about a congested network

Exactly.
It allows nearby clients/nodes to make MUCH better decisions. [1]

> or in other words: does it solve a problem?

###
Essentially, very small local channel utilization measurement reports
are broadcasted to all direct neighbors by piggybacking them onto
IEEE802.11 beacons. [2]
###

1) Maintainers could better distinguish causes of link problems [3]
2) Our current algorithms for rate control, routing and
network-selection could make better decisions if they have access this
"remote channel load" statistic.

So, we think this feature could be really helpful. It increases the
networks capability to self-regulate, for a small price. [4]


-paul

PS: Arthur did all the hard work, I'm just doing the cheap talking.






[1] that is probably the reason for recent AP models in the enterprise
segment already broadcasting it.

[2] channel utilization measured at the receive antenna port of the
device that is sending that beacon.

[3] if LTE-U/LAA/muLTEfire becomes widespread :( we need a way to detect
that such a nearby non-IEEE80211 source is blocking the channel.

[4] Currently, OpenWRT sends around 200bytes PSDUs per beacon (depending
on mode etc). Assuming a 100ms beacon interval and 1Mbit/s, adding
these 7 bytes to them would increase the channel utilization each
beaconing node is generating by less than 0.06% of total airtime.

_______________________________________________
Battlemesh mailing list
Battlemesh@ml.ninux.org
http://ml.ninux.org/mailman/listinfo/battlemesh


-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast

Re: [Make-wifi-fast] Fwd: [Battlemesh] BSS load element patch

[Michael Welzl]

Hi,

I find this intriguing:


> On 07 Aug 2015, at 12:09, Dave Taht <dave.taht@gmail.com> wrote:
> 
> ---------- Forwarded message ----------
> From: Paul Fuxjaeger <fuxjaeger@ftw.at>
> Date: Fri, Aug 7, 2015 at 11:28 AM
> Subject: Re: [Battlemesh] BSS load element patch
> To: Battle of the Mesh Mailing List <battlemesh@ml.ninux.org>
> 
> 
> On 05.08.15 14:57, Bastian Bittorf wrote:
> 
>> Does e.g. a client gets informed about a congested network
> 
> Exactly.
> It allows nearby clients/nodes to make MUCH better decisions. [1]

Does anybody have information about how this is being used? Any examples?

Cheers,
Michael


> 
>> or in other words: does it solve a problem?
> 
> ###
> Essentially, very small local channel utilization measurement reports
> are broadcasted to all direct neighbors by piggybacking them onto
> IEEE802.11 beacons. [2]
> ###
> 
> 1) Maintainers could better distinguish causes of link problems [3]
> 2) Our current algorithms for rate control, routing and
> network-selection could make better decisions if they have access this
> "remote channel load" statistic.
> 
> So, we think this feature could be really helpful. It increases the
> networks capability to self-regulate, for a small price. [4]
> 
> 
> -paul
> 
> PS: Arthur did all the hard work, I'm just doing the cheap talking.
> 
> 
> 
> 
> 
> 
> [1] that is probably the reason for recent AP models in the enterprise
> segment already broadcasting it.
> 
> [2] channel utilization measured at the receive antenna port of the
> device that is sending that beacon.
> 
> [3] if LTE-U/LAA/muLTEfire becomes widespread :( we need a way to detect
> that such a nearby non-IEEE80211 source is blocking the channel.
> 
> [4] Currently, OpenWRT sends around 200bytes PSDUs per beacon (depending
> on mode etc). Assuming a 100ms beacon interval and 1Mbit/s, adding
> these 7 bytes to them would increase the channel utilization each
> beaconing node is generating by less than 0.06% of total airtime.
> 
> _______________________________________________
> Battlemesh mailing list
> Battlemesh@ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/battlemesh
> 
> 
> -- 
> Dave Täht
> worldwide bufferbloat report:
> http://www.dslreports.com/speedtest/results/bufferbloat
> And:
> What will it take to vastly improve wifi for everyone?
> https://plus.google.com/u/0/explore/makewififast
> _______________________________________________
> Make-wifi-fast mailing list
> Make-wifi-fast@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/make-wifi-fast

Re: [Make-wifi-fast] Fwd: [Battlemesh] BSS load element patch

[Dave Taht]

the battlemesh threads are here:


http://ml.ninux.org/pipermail/battlemesh/2015-August/003645.html

http://ml.ninux.org/pipermail/battlemesh/2015-August/003745.html

On Fri, Aug 7, 2015 at 12:55 PM, Michael Welzl <michawe@ifi.uio.no> wrote:
> Hi,
>
> I find this intriguing:
>
>
>> On 07 Aug 2015, at 12:09, Dave Taht <dave.taht@gmail.com> wrote:
>>
>> ---------- Forwarded message ----------
>> From: Paul Fuxjaeger <fuxjaeger@ftw.at>
>> Date: Fri, Aug 7, 2015 at 11:28 AM
>> Subject: Re: [Battlemesh] BSS load element patch
>> To: Battle of the Mesh Mailing List <battlemesh@ml.ninux.org>
>>
>>
>> On 05.08.15 14:57, Bastian Bittorf wrote:
>>
>>> Does e.g. a client gets informed about a congested network
>>
>> Exactly.
>> It allows nearby clients/nodes to make MUCH better decisions. [1]
>
> Does anybody have information about how this is being used? Any examples?
>
> Cheers,
> Michael
>
>
>>
>>> or in other words: does it solve a problem?
>>
>> ###
>> Essentially, very small local channel utilization measurement reports
>> are broadcasted to all direct neighbors by piggybacking them onto
>> IEEE802.11 beacons. [2]
>> ###
>>
>> 1) Maintainers could better distinguish causes of link problems [3]
>> 2) Our current algorithms for rate control, routing and
>> network-selection could make better decisions if they have access this
>> "remote channel load" statistic.
>>
>> So, we think this feature could be really helpful. It increases the
>> networks capability to self-regulate, for a small price. [4]
>>
>>
>> -paul
>>
>> PS: Arthur did all the hard work, I'm just doing the cheap talking.
>>
>>
>>
>>
>>
>>
>> [1] that is probably the reason for recent AP models in the enterprise
>> segment already broadcasting it.
>>
>> [2] channel utilization measured at the receive antenna port of the
>> device that is sending that beacon.
>>
>> [3] if LTE-U/LAA/muLTEfire becomes widespread :( we need a way to detect
>> that such a nearby non-IEEE80211 source is blocking the channel.
>>
>> [4] Currently, OpenWRT sends around 200bytes PSDUs per beacon (depending
>> on mode etc). Assuming a 100ms beacon interval and 1Mbit/s, adding
>> these 7 bytes to them would increase the channel utilization each
>> beaconing node is generating by less than 0.06% of total airtime.
>>
>> _______________________________________________
>> Battlemesh mailing list
>> Battlemesh@ml.ninux.org
>> http://ml.ninux.org/mailman/listinfo/battlemesh
>>
>>
>> --
>> Dave Täht
>> worldwide bufferbloat report:
>> http://www.dslreports.com/speedtest/results/bufferbloat
>> And:
>> What will it take to vastly improve wifi for everyone?
>> https://plus.google.com/u/0/explore/makewififast
>> _______________________________________________
>> Make-wifi-fast mailing list
>> Make-wifi-fast@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>



-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast