gluon-core: make wifi rates configurable #810

kb-light · 2016-07-01T13:06:54Z

First commit adds a new function to check_site_lib.lua, to check whether a value is included in a given array. This is needed, to check that the list of wifi rates only contains unprohibited values.

Second commit adds the functionality to specify a list of allowed wifi rates within site.conf, which was already discussed in #467. Additionally this should fix all issues mentioned by @NeoRaider in #808.

Thanks to:
@RubenKelevra
@Brother-Lal
@rotanid

T-X · 2016-07-11T14:49:35Z

Just like the other pull requests, the idea looks very interesting and tempting :-). I'd be very excited to see some statistics showing how much things get improved by this (for instance reduced airtime or increased overall throughput on a couple of real-world example nodes, vs. number of clients connected to a node).

Also, what kind of devices (including operating system + wifi driver) have you tested this with? Just to make sure it does not introduce any compatibility issues.

florianjacob · 2016-07-21T22:03:00Z

👍 for having at least the possibility to turn 802.11b off, we discussed that today at the Freifunk Karlsruhe meeting and decided to investigate how this could be achieved. ✨

For reference, some numbers can be found in this article, Cisco recommends turning of 802.11b since 2014:

In addition to the overhead created by the SSID’s you also have 802.11g protection mechanism that requires sending of an 802.11b packet reserving the airtime to then send the 802.11g or 802.11n packet – that’s two packets for every single user data packet – and this translates to as much as a 50% reduction of available bandwidth.

See – a very high tax indeed. Stop the madness – turn it off. Disabling 1,2,5.5, and 11 Mbps data rates will dramatically improve 2.4 GHz availability availability for usable traffic and throughput, which can translate to a savings of 30-50%.
http://blogs.cisco.com/wireless/wi-fi-taxes-digging-into-the-802-11b-penalty

neocturne · 2016-07-26T22:42:59Z

scripts/check_site_lib.lua

@@ -103,3 +103,26 @@ function need_string_array(varname, required)
   return assert(pcall(need_array, varname, function(e) assert_type(e, 'string') end, required),
 		 "site.conf error: expected `" .. varname .. "' to be a string array")
 end
+
+function need_var_in_array(varname, array, required)


Most of this function could be replaced by a call to need_array, similar to the way need_string_array is defined. I think it would make sense to split this function into two - one that just checks if a value is one of list of possible values (maybe need_one_of), and one that works like need_string_array and calls need_array with need_one_of (could be called need_array_of).

kgbvax · 2016-07-26T23:03:35Z

The rate given are are missing 802.11n rates and thus I understand that this limited speed to ancient 54Mbit. (I admit that this may cover most of the freifunk use cases). Anyway I think if something like that is included, this should also include the 802.11n rates / MCS indices. OpenWrt "bitrate" knows mixed notation for this

bitrates [legacy-<2.4|5> ] [ht-mcs-<2.4|5> ] [vht-mcs-<2.4|5> <NSS:MCSx,MCSy... | NSS:MCSx-MCSy>*] [sgi-2.4|lgi-2.4] [sgi-5|lgi-5]

However I am not qualified to assess whether this works for basic_rate / supported_rates as well. The documentation does not say so.

neocturne · 2016-07-26T23:16:57Z

@kgbvax, I was confused by this at first, too, but it was explained to me that basic_rate / supported_rates doesn't affect 11n rates (which are so-called "extended rates").

mweinelt · 2016-07-28T18:03:13Z

How does the availability of basic or supported rates relate to the mcast_rate?

rotanid · 2016-07-31T23:22:03Z

scripts/check_site_lib.lua

+
+function need_array_of(varname, array, required)
+   return assert(pcall(need_array, varname, need_one_of(e, array),required),
+                 "site.conf error: expacted `" .. varname .. "' to be a subset of given array")


typo, should be "expected" instead of "expacted"

neocturne · 2016-07-31T23:31:23Z

scripts/check_site_lib.lua

 function need_string_array(varname, required)
   return assert(pcall(need_array, varname, function(e) assert_type(e, 'string') end, required),
 		 "site.conf error: expected `" .. varname .. "' to be a string array")
 end
+
+function need_array_of(varname, array, required)
+   return assert(pcall(need_array, varname, need_one_of(e, array),required),


This call is wrong - you need to wrap the need_one_of into an anonymous function like it is done in need_string_array

rotanid · 2016-08-11T22:06:46Z

just adding a note, so @neoraider knows something was done here and his label "changes requested" is obsolete

neocturne · 2016-08-11T22:19:12Z

Thanks, already noticed, I'm a bit busy this week though...

viisauksena · 2016-08-14T02:23:34Z

just a sidenode, [i'd love to see this default in gluon]
this only maintain 80211 a , blocking b and not touching n at all ...
this may be fine, maybe we want to add beacon_int (default 100 - integer between 15 and 65k) also , maybe require_mode
i did some testing, the result is that there is still a bunch of 1Mbit Beacons .. every 100ms
.. see here https://forum.freifunk.net/t/client-basic-rate-setzen-um-1mbit-verbindungen-zu-blocken/13286

neocturne · 2016-08-14T04:13:19Z

Beacons don't really matter, they are small, and one every 100ms shouldn't have any noticable effect on the airtime anyways.
Beacons are sent using the multicast rate, which is configured independently of the basic/supported rates.

RubenKelevra · 2016-08-14T09:31:43Z

@viisauksena first of all the "usage of channel airtime" stats of horst cannot be trusted:

br101/horst#45

Secondly if you used the following:

uci set wireless.client_radio0.basic_rate="5500 6000 9000 11000 12000 18000 20000 24000 30000 36000 40000 42000 44000 48000 50000 51000"

... it won't work because it's just wrong. There are still some B-Rates and there are some non-existing ones.

I guess it will just ignored by the driver.

RubenKelevra · 2016-08-14T09:40:19Z

@viisauksena in the End, your conclusion is wrong, becons are sent with 6 mbits after this patch:

@NeoRaider

Beacons are sent using the multicast rate, which is configured independently of the basic/supported rates.

Beacons are sent with the lowest supported rate, since this are all the hotspot supports ... ;)

viisauksena · 2016-08-14T13:49:59Z

@NeoRaider based on my observation youre right for beacon rate in ibss0 - this seems based on mcast rate, but against @RubenKelevra mentioning i observe 1 Mbit beacons for client0 AP half the time ... see esp. here
https://forum.freifunk.net/uploads/default/original/2X/2/2c7aa7d804d458666bfd6c3a160d1f70aafe1804.png

i should also have mentioned that i use ure supported list rates and not my blind guessings in the beginning.

# this is the used setup on all cpe and 841 Routers 
uci set wireless.ibss_radio0.mcast_rate='24000'
uci set wireless.client_radio0.supported_rate='6000 9000 12000 18000 24000 36000 48000 54000'
uci set wireless.client_radio0.basic_rate='6000 9000 18000 36000 48000 54000'
uci commit 
wifi

RubenKelevra · 2016-08-14T14:34:06Z

@viisauksena

mcast_rate 24000 is insane. 12000 like used in luebeck is somewhat high, I guess. I would recommend 6 mbit for this.

Else, your setup is broken, since this works as I've said:

Which gluon-commit did you compile?

viisauksena · 2016-08-14T14:48:33Z

@RubenKelevra this is somehow offtopic , and should be discussed somewhere else - i guess,
but to answer your questions .. see this insane setup here http://openfreiburg.de/freifunk/meshviewer/#!v:m;n:60e327df06b0 there my mentioned setup is running as described. there a no cables involved, on the left there are three different uplinks on cpe routers - all links seem pretty stable - the build is 2016.1.5 ... more detailed Linux version 3.18.29 (fffr@build) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r49261) ) #5 Mon Jun 27 01:57:57 CEST 2016 ... so this is build on that day with latest/master

edit wrote an email and go on to discuss it in Freifunk Forum
leaving the suggestion to add beacon_int and/or require_mode

rotanid · 2016-08-14T14:53:36Z

could you please take this discussion elsewhere?
you are not contributing to this pull request but rather making it confusing to find the relevant posts here.
feel free to discuss this in a new issue, on IRC or on the mailing list :)

neocturne · 2016-08-26T20:04:17Z

scripts/check_site_lib.lua

@@ -133,8 +133,9 @@ function need_one_of(varname, array, required)
 end

 function need_string_array(varname, required)
-   return assert(pcall(need_array, varname, function(e) assert_type(e, 'string') end, required),
-		 "site.conf error: expected `" .. varname .. "' to be a string array")
+   assert(pcall(need_array, varname, function(e) assert_type(e, 'string') end, required),


Hmm, the pcall should return two values, a true/false value and the original return value of need_array, we're just discarding the second one by passing it to assert. I think we could do without the extra loadvar like this (untested):

local ok, var = pcall(need_array, varname, function(e) assert_type(e, 'string') end, required) assert(ok, "site.conf error: expected `" .. varname .. "' to be a string array") return var

…b.lua need_one_of(varname, array, required) checks weather the value of the specified variable is part of given array. need_array_of(varname, array, required) is similar to need_one_of() but assume that varname points to an array.

neocturne · 2016-08-26T22:57:19Z

docs/site-example/site.conf

+    -- Example removes 802.11b compatibility for better performance
+    supported_rates = {6000, 9000, 12000, 18000, 24000, 36000, 48000, 54000},
+
+    -- List of basic wifi rates (optional, recommended if supported_rates is set)


This comment doesn't match the check_site script: the script makes basic_rate mandatory if supported_rates is set, not just recommended.

That should be required. I updated docs/user/site.rst, too, to sound the same.

and add documentation

…t_rate

kb-light · 2016-08-27T05:21:23Z

package/gluon-core/check_site.lua

+
+    local rates = {1000, 2000, 5500, 6000, 9000, 11000, 12000, 18000, 24000, 36000, 48000, 54000}
+    local supported_rates = need_array_of(config .. '.supported_rates', rates, false)
+    if supported_rates then


@NeoRaider: I don't like this if, but I think it is more clear than:
need_array_of(config .. '.basic_rate', supported_rates or rates, supported_rates and true or false)

rubo77 · 2016-09-30T14:32:54Z

for others searching for this, I add the examples from http://gluon.readthedocs.io/en/v2016.2/user/site.html?highlight=basic_rate

    -- Example removes 802.11b compatibility for better performance
    supported_rates = {6000, 9000, 12000, 18000, 24000, 36000, 48000, 54000},

    -- List of basic wifi rates (optional, required if supported_rates is set)
    -- Example removes 802.11b compatibility for better performance
    basic_rate = {6000, 9000, 18000, 36000, 54000},

the question is how to configure this if you DONT want to disable 802.11b?

mweinelt · 2016-09-30T14:58:50Z

I'd assume adding 5500 (and optionally 1000 and 2000) would do that.

viisauksena · 2016-09-30T15:11:01Z

or dont configure this optional feature at all

rubo77 · 2016-09-30T17:08:34Z

And does this interact with the mcast_rate setting? and how?

kb-light · 2016-09-30T17:11:26Z

@rubo77: mcast_rate should be part of supported_rates (if supported_rates is set)

rubo77 · 2016-10-01T14:38:02Z

As far as I understand, if you set mcast_rate to for example 12000, then no links slower or faster than 12MBit are created, so you are not able to send faster than 12MBit either.

I would like to configure it, so our mesh sends minimum 12000 but also faster, if the link is good.

Is that possible with those three options supported_rates, basic_rate and mcast_rate?

see also: https://forum.freifunk.net/t/moegliche-werte-fuer-mcast-rate/11785/13

neocturne · 2016-10-01T14:46:12Z

mcast_rate is used for multicast packets only. The multicast rate is always fixed and defaults to 1MBit/s. We recommend setting it to a higher value like 12MBit/s to reduce the airtime used by the background noise. This setting affects the mesh links only, not the clients links (as it is unknown if all clients work with multicast rates other than 1MBit/s).

The unicast rate is completely independent of this and is negotiated for each peer and client independently. It may be higher or lower than the multicast rate.

supported_rates and basic_rate control the allowed unicast rates for both mesh and client links. They are mainly useful to prevent the use of legacy 802.11b rates, which may impair the overall WLAN performance. Also, these settings don't affect the "extended rates" (802.11n, everything higher than 54MBit/s), these are always allowed additionally.

rubo77 · 2016-11-16T18:12:24Z

This should be added in the docs here: http://gluon.readthedocs.io/en/latest/user/site.html

I see the hint to use something like 12MBit is new, but there should be some more explained:

This setting affects the mesh links only

does that mean, that all traffic between nodes is limited to 12MBit?

viisauksena · 2016-11-16T20:22:05Z

@rubo77 it is not "limited" - it is set fixed - thus making throughput in achain of meshing nodes realy horrible
(i would also suggest to set it to 18000 or 24000 )

rubo77 · 2016-11-16T23:08:52Z

Why is this set fixed? Isn't there a way to get the maximum speed possible of each mesh connection?

RubenKelevra · 2016-11-16T23:30:31Z

@rubo77 it's fixed because this is how wifi works, so no.

rubo77 · 2016-11-17T07:09:41Z

It is not all set fixed, Unicast is not.

NeoRaider said:

The mcast_rate is only used for multicast traffic, which is management traffic (WLAN beacons, batman-adv OGMs) and multicast/broadcast payloads (ARP, ICMPv6, ...). It is fixed as multicast packets are not directed to any specific recipient, but sent only once for all peers, so there is no negotiation.

Unicast packets are sent only to a single peer and are thus sent with higher or lower bitrate, which is negotiated with the peer individually

ce53ed2

(So a speedtest from a node that's connected to a fast offloaded only via mesh nodes should be much faster, or did you observe a different behaviour?)

Maybe we should add the second Paragraph to the manual, so this common misunderstanding gets wiped out.

RubenKelevra · 2016-11-18T08:57:14Z

The setting is called mcast rate, why should unicast be fixed than? Your concerns makes absolutely no sense.

rubo77 · 2016-11-18T18:31:22Z

Look in the forum. Many Admins think this would Set Both fixed

T-X · 2017-01-07T16:15:26Z

Because of the lack of statistics I'm still a little sceptical regarding the general applicability of this feature. For instance while in your 300 nodes mesh there might be ten nodes with too many clients, where this feature is needed to make the node usable at least for the clients in closer range. But there might also be ten other nodes with less clients where clients a little more far away are kicked even though they do no harm.

However, why I'm writing now is actually this patch which I think could put this feature on steroids, if someone were adding another patch to have it available not only for AP, but also IBSS/802.11s interfaces: https://patchwork.ozlabs.org/patch/697637/

For instance we could have a required basic rate of maybe 6 or 12MBit/s for all interfaces. And then safely disable wifi broadcasts all together with this mac80211 multicast-to-unicast patch.

PS: Disabling broadcasts on IBSS/802.11s is only applicable for routing protocols using a throughput instead of packetloss based metric (currently this is OLSRv2 or BATMAN V).

rubo77 · 2017-01-08T08:57:50Z

Couldn't we make the configuration depending on the nr of connected clients somehow?

kb-light force-pushed the wlan-rates branch from c022586 to 80d5644 Compare July 7, 2016 03:33

sarumpaet mentioned this pull request Jul 15, 2016

Set basic_rate for AP/ad-hoc freifunk-berlin/firmware#375

Closed

kb-light force-pushed the wlan-rates branch from 80d5644 to d01d091 Compare July 15, 2016 18:10

neocturne reviewed Jul 26, 2016
View reviewed changes

neocturne added this to the 2016.2 milestone Jul 27, 2016

neocturne added 0. type: enhancement The changeset is an enhancement changes requested labels Jul 27, 2016

rotanid reviewed Jul 31, 2016
View reviewed changes

kb-light force-pushed the wlan-rates branch from 931a570 to ae5c28b Compare July 31, 2016 23:30

neocturne reviewed Jul 31, 2016
View reviewed changes

kb-light force-pushed the wlan-rates branch 2 times, most recently from 846c516 to b5c14aa Compare August 3, 2016 09:14

kb-light force-pushed the wlan-rates branch from b5c14aa to 372a54a Compare August 26, 2016 19:23

neocturne reviewed Aug 26, 2016
View reviewed changes

kb-light force-pushed the wlan-rates branch from 372a54a to 07f6e3e Compare August 26, 2016 21:22

kb-light added 2 commits August 26, 2016 23:28

scripts: update need_string_array() to work as expected

4d98fbb

kb-light force-pushed the wlan-rates branch from 07f6e3e to 07bdcbb Compare August 26, 2016 21:28

neocturne reviewed Aug 26, 2016
View reviewed changes

kb-light added 2 commits August 27, 2016 07:11

gluon-core: make wifi rates configurable by site.conf

6ff94ac

and add documentation

gluon-mesh-batman-adv-core: use need_one_of() to check for valid mcas…

81280d8

…t_rate

kb-light force-pushed the wlan-rates branch from 07bdcbb to 81280d8 Compare August 27, 2016 05:12

kb-light reviewed Aug 27, 2016
View reviewed changes

neocturne removed the changes requested label Aug 27, 2016

neocturne merged commit 81280d8 into freifunk-gluon:master Aug 27, 2016

rubo77 referenced this pull request Nov 16, 2016

docs: user/site: improve mcast_rate description

ce53ed2

gluon-core: make wifi rates configurable #810

gluon-core: make wifi rates configurable #810

Conversation

kb-light commented Jul 1, 2016 • edited Loading

T-X commented Jul 11, 2016

florianjacob commented Jul 21, 2016 • edited Loading

Choose a reason for hiding this comment

kgbvax commented Jul 26, 2016

neocturne commented Jul 26, 2016

mweinelt commented Jul 28, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rotanid commented Aug 11, 2016

neocturne commented Aug 11, 2016

viisauksena commented Aug 14, 2016 • edited Loading

neocturne commented Aug 14, 2016

RubenKelevra commented Aug 14, 2016

RubenKelevra commented Aug 14, 2016 • edited Loading

viisauksena commented Aug 14, 2016

RubenKelevra commented Aug 14, 2016 • edited Loading

viisauksena commented Aug 14, 2016 • edited Loading

rotanid commented Aug 14, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rubo77 commented Sep 30, 2016

mweinelt commented Sep 30, 2016

viisauksena commented Sep 30, 2016

rubo77 commented Sep 30, 2016

kb-light commented Sep 30, 2016

rubo77 commented Oct 1, 2016

neocturne commented Oct 1, 2016

rubo77 commented Nov 16, 2016 • edited Loading

viisauksena commented Nov 16, 2016 • edited Loading

rubo77 commented Nov 16, 2016

RubenKelevra commented Nov 16, 2016

rubo77 commented Nov 17, 2016 • edited Loading

RubenKelevra commented Nov 18, 2016

rubo77 commented Nov 18, 2016

T-X commented Jan 7, 2017 • edited Loading

rubo77 commented Jan 8, 2017

kb-light commented Jul 1, 2016 •

edited

Loading

florianjacob commented Jul 21, 2016 •

edited

Loading

viisauksena commented Aug 14, 2016 •

edited

Loading

RubenKelevra commented Aug 14, 2016 •

edited

Loading

RubenKelevra commented Aug 14, 2016 •

edited

Loading

viisauksena commented Aug 14, 2016 •

edited

Loading

rubo77 commented Nov 16, 2016 •

edited

Loading

viisauksena commented Nov 16, 2016 •

edited

Loading

rubo77 commented Nov 17, 2016 •

edited

Loading

T-X commented Jan 7, 2017 •

edited

Loading