Optimierung der WLAN Datenraten am Beispiel Aachen

Technik
1

Wir verabschieden uns in Aachen nun endlich von den 80211.b Datenraten die in Gluon noch aktiv sind und erlauben bis auf 1Mbit runter zu schalten, nun ist die langsamste Option 6Mbit

https://github.com/ffac/site/commit/a65f0e74ba41ab3e98adca0061c50cea3c9cc4aa

Wir hatten zwar die Befürchtung, dass dies zum verschwinden von bisher schwachen Links führen könnte, da diese aber so oder so nicht nutzbar sind haben wir uns davon nicht abhalten lassen.

Erfreulicherweise hat sich jedoch meine Hoffung bestätigt, dass selbst diese schwachen links von dieser Maßnahme profitieren, da die Airtime effektiver genutzt wird.

Hier das beispiel eins Links der hart am Limit ist:

migration_zweite_seite.png1511×680 124 KB

Dieser Link war bisher nur gelegentlich vorhanden, nach der Umstellung der ersten Seite vor einigen Tagen war diese Richtung schwach, aber stabil, nachdem nun beide Seiten umgestellt sind, sind beide Richtungen dauerhaft vorhanden.

Auch bisher passable Links werde deutlich stärker:

migration_blau.png1511×680 89.7 KB

In ecken mit mehreren Knoten sind teilweise Mesh links dazu gekommen, die zuvor nicht vorhanden waren:

khg.png1511×680 138 KB

Mittelmäßige Links konnten auch noch etwas heraus holen:

ihk.png1511×680 255 KB

Davon abgesehen, verbessern wir damit nicht nur unser Netz, wir geben zusätzlich massiv Airtime für andere Netze frei, damit können die anderen Netze ihren Traffic schneller abwickeln. Es bleibt wiederum mehr Airtime, auch für uns.

Welche Datenraten nutzt ihr? Ist es vielleicht Sinnvoll noch einen Schritt weiter zu gehen und auch die 802.11g Datenraten zumindest teilweise zu entfernen und primär auf 802.11n zu setzen?

14 „Gefällt mir“
2

Ich habe bei uns jetzt mal auf 12000 hochgesetzt, einfach weil das Airtime-Problem durch grenzwertig eingebuchte Clients wirklcih zu drücken scheint.
Und anderseits: Viele Nutzende werden sich bedanken, lieber kein als ein extrem schwaches Freifunk innerstädtisch zu sehen, wo dann nur „eingeschränkte Connectivität“ ist. (aka: nicht mal Antwort auf DHCP-Requests…)

1 „Gefällt mir“
3

Ihr habt doch ein recht Umfangreiches Montoring oder? Kannst du in den Daten einen entsprechenden Effekt feststellen?

4

Es ist experimentell auf 5 Routern… es ist noch zu früh für qualifizierte Aussagen.

5

wenn ich das nun richtig erinnere und zuordne hab ich das hier ähnlich beobachtet, bessere und stabilere Links, aber auch - und da hab ich noch keine Idee woher das kommt.
Router mit vielen Links crashen übelst schnell - die einzelnen Lücken deuten bei euch auch darauf hin.
ich weis nicht ob das zutrifft, ich hab aber hier Router mit 5++ Links (geht weit über die 10 hinaus - die gern/oft crashen) - bisher hab ich nur die Anzahl der Mesh Links dazu ausgemacht. kannst du dazu mehr sagen, oder hast ne idee dazu?

                        mcast_rate = 18000,
...
                supported_rates = {6000, 9000, 12000, 18000, 24000, 36000, 48000, 54000},
                basic_rate = {6000, 9000, 18000, 24000, 36000, 54000},
1 „Gefällt mir“
6

Nunja, durch zusätzliche mesh links muss der Router mit zusätzlichen Routen im Mesh klar kommen und diese verwalten. Das wird die Load tatsächlich erhöhen, aber sofern es nicht eine riesen Domäne ist in der die Router eh schon am limit laufen sollte das wirklich nicht ins Gewicht fallen.

Ich habe bisher keine Hinweise auf zusätzliche Reboots nach dem Flash gesehen.

7

@MrMM danke für die Infos. Sieht gut aus.

Ich schreibe gerade eine Bachelor-Arbeit zu dem Thema. Kurz zusammengefasst: „Lohnt sich das Abschalten alter Standards“. Eure Erfahrung bestätigen alle Vermutungen und Voruntersuchungen.
Falls ihr Rohdaten zum Vergleich vorher / nachher habt, oder wenn eine andere Community das gleiche vor hat, dann würde ich mich RIESIG über Daten jeglicher Art freuen. Sprecht mich gerne hier oder per PN an.

Nach Abschluss (in ein paar Monaten?) werde ich die Erkenntnisse auch gebündelt an die Freifunk-Community weitergeben. Aber so wie ich uns alle kenne sind bis dahin fast alle Communitys schon umgestellt :wink:

8

Leider haben wir in den respondd-Datagrammen nicht, was die Linkspeed (oder gar MCS&Co) zum Nachbarknoten ist.
Ansonsten könnte man da recht bequem über einen Zeitraum schnorcheln.

Gibt’s irgendein script, was man auf einem größeren Router laufen lassen könnte, was Meshperformance irgendwie per -protokoll der wahl- dumped?

9

Naja, die TQ hat doch schon eine klare Aussage: Paketverlust nimmt ab

Interessant wäre auch daneben zu messen wie viel Airtime frei ist, sehr einfach machbar mit einer Fritzbox. Die frage ist ob das für deine Zwecke ausreichend genau ist.

10

Versuch mal so mit den Werten:

  •   supported_rates = {6000, 9000, 12000, 18000, 24000, 36000, 48000, 54000},

  •   basic_rate = {6000, 12000, 24000},

963×310 88.6 KB

Die Basic sind nur für Multicast

11

Was Host der Hintergrund für dieses Setting, insbesondere: Warum sollte für Multicast nicht auch 54k zulässig sein?

1 „Gefällt mir“
12

Ähnlich wie bei Dir, hat man gemerkt das die WLAN b nur Balast für die Performance aller Geräte ist. Bei Ubiquiti hat man die Werte dann mal so in ein Beta glaube ab 5.0.6 Controller so übernommen.

Meine Vermutung ist bei Multicast, weil alle an einen Stream mit-lauschen und es keine derart großen Streams gibt, hat man das Setting bei Ubiquiti so als sehr gut befunden ins Default geschrieben.

1 „Gefällt mir“
13

Okay, das sind also die aktuellen Defaults vobn ubiquiti, nun ergibt dein Post für mich Sinn.

Für uns sollten die hohen Raten auch für Broad-/Multicast vorgesehenen sein. Ich kennen Setups mit starken wlan mesh Verbindungen, diese sollten in der Lage sein mit diesen Raten deutlich effektiver zu arbeiten.

1 „Gefällt mir“
14

Ja das Problem ist wohl das die 802.11b eine Kanalbandbreite von 22 MHZ verwendet. Daher die Kanäle 1,6,11 verwendet wurden. Ohne 802.11b kann man gut 1,5,9,13 verwenden mit 20 MHZ Kanalbandbreite.

15

Hab da mal ne Grundsatzfrage:
Wird das fest in der Firmware eingestellt oder kann das an jedem Router (per UCI?) geändert werden?
(falls UCI, wie wäre das Commando um WLAN „B“ zu deaktivieren)

16

siehe hier:
https://github.com/freifunk-gluon/gluon/pull/810

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

Das sollte 11b deaktivieren.
Für die Gluonconfig, siehe hier:
http://gluon.readthedocs.io/en/v2016.2/user/site.html?highlight=basic_rate

Edit;
Um deine Frage zu beantworten: Es ist per uci einstellbar, wird aber seit dem oben genannten Pull-request auch als globale Option für die gesamte Gluon-Firmware akzeptiert (welcher dann beim bauen einfach die Uci-Optionen setzt.)

4 „Gefällt mir“
17

@biggersee falls du das in einem hübschen Mesh testet, mach doch zumindest ein paar vorher nachher Screenshots von der Map, oder besser noch schone Graphen.

Sehr spannend wäre auch weiter zu gehen und das vorgeschlagene Setup mit Raten nur ab 12000 zu testen.

18

Ich baue gerade eine Experimental mit site.conf

        supported_rates = { 12000, 18000, 24000, 36000, 48000, 54000 },
        basic_rate = { 12000, 18000, 24000, 36000, 48000, 54000 },

und ja, es gibt auch einen Testkandidaten dafür, bei dem ich bislang keinen alternativen Therapieansatz gefunden habe, da wirklich alle Knoten Wifimesh brauchen und ich die Sendeleistung auch nicht reduzieren kann, da die Stationen die Mobilgeräte erreichen müssen, die evtl. „hinter zwei Wänden und einem regennassen Kirschlorbeer“ sitzen.

grafik.png610×533 192 KB

2 „Gefällt mir“
19

Wäre es nicht zweckmäßiger einfach nur die wireless config anzupassen statt ein neues image zu bauen?

20

VORHER

grafik.png1120×791 300 KB

NACHHER / Aktuell

grafik.png892×959 270 KB

GEÄNDERT wurden diese Knoten: