* [Make-wifi-fast] Fwd: [Battlemesh] BSS load element patch [not found] <55BFBBF1.4080709@lena.im> @ 2015-08-07 10:08 ` Dave Taht [not found] ` <20150805125746.GR25597@medion.lan> 1 sibling, 0 replies; 4+ messages in thread From: Dave Taht @ 2015-08-07 10:08 UTC (permalink / raw) To: make-wifi-fast, cerowrt-devel [-- 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; + } ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <20150805125746.GR25597@medion.lan>]
[parent not found: <55C47A29.5010402@ftw.at>]
* [Make-wifi-fast] Fwd: [Battlemesh] BSS load element patch [not found] ` <55C47A29.5010402@ftw.at> @ 2015-08-07 10:09 ` Dave Taht 2015-08-07 10:55 ` Michael Welzl 0 siblings, 1 reply; 4+ messages in thread From: Dave Taht @ 2015-08-07 10:09 UTC (permalink / raw) To: make-wifi-fast ---------- 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Make-wifi-fast] Fwd: [Battlemesh] BSS load element patch 2015-08-07 10:09 ` Dave Taht @ 2015-08-07 10:55 ` Michael Welzl 2015-08-07 17:21 ` Dave Taht 0 siblings, 1 reply; 4+ messages in thread From: Michael Welzl @ 2015-08-07 10:55 UTC (permalink / raw) To: Dave Taht; +Cc: make-wifi-fast 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Make-wifi-fast] Fwd: [Battlemesh] BSS load element patch 2015-08-07 10:55 ` Michael Welzl @ 2015-08-07 17:21 ` Dave Taht 0 siblings, 0 replies; 4+ messages in thread From: Dave Taht @ 2015-08-07 17:21 UTC (permalink / raw) To: Michael Welzl; +Cc: make-wifi-fast 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-08-07 17:21 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <55BFBBF1.4080709@lena.im> 2015-08-07 10:08 ` [Make-wifi-fast] Fwd: [Battlemesh] BSS load element patch Dave Taht [not found] ` <20150805125746.GR25597@medion.lan> [not found] ` <55C47A29.5010402@ftw.at> 2015-08-07 10:09 ` Dave Taht 2015-08-07 10:55 ` Michael Welzl 2015-08-07 17:21 ` Dave Taht
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox