Was Host der Hintergrund für dieses Setting, insbesondere: Warum sollte für Multicast nicht auch 54k zulässig sein?
1 „Gefällt mir“
Ä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“
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“
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.
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)
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“
@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.
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.
2 „Gefällt mir“
Wäre es nicht zweckmäßiger einfach nur die wireless config anzupassen statt ein neues image zu bauen?
VORHER
NACHHER / Aktuell
GEÄNDERT wurden diese Knoten:
but „don’t“ trust the map …
hi
blöde frage, warum nicht einfach:
uci set wireless.${radio}.require_mode=‚g‘
(${radio} natürlich durch das Radio ersetzen)
das sollte b doch auch deaktivieren oder?
mfg
Christian
Ja definitiv, allerdings ist dies in openWRT dann als „g only“ beschrieben. Weitere Optionen waren meine ich bgn, b only, n only. Eine Option gn vermisse ich.
Wäre interessant hier nach Dokumentation zu graben was jeweils genau hinter diesen Optionen steckt.
Also wenn du das meinst, was ich denke was du meinst, sprichst du grade von hwmode:
Selects the wireless protocol to use, possible values are 11b, 11g, and 11a (note that 11ng and 11na are not available options, see ticket 17541)
Und hier geht es um require_mode:
(ap mode) Set the minimum mode that connecting clients need to support to be allowed to connect. Supported values: g = 802.11g, n = 802.11n, ac = 802.11ac
https://wiki.openwrt.org/doc/uci/wireless#common_device_options
Gute Frage eigentlich.
Gingen die Links die nun nicht mehr da sind eventuell zuvor nur in eine Richtung?
Irgendeinen zeitlichen Verlauf hast du nicht zur Verfügung oder?
Wobei die bestehenden Links ja auch stärker geworden sind, nur ein paar ganz schwache waren momentan weg, momentan sind die auch wieder da.
wollte hier nur mein generelles Mistrauen der MAP gegenüber zum Ausdruck bringen 
War schon öfter so das Nodes als offline dargestellt wurden, aber defacto online waren…
Über warum man nicht require_mode verwendet wurde damals bei der Implementierung zum Ändern der Raten in Gluon diskutiert. Aber anscheinend werden dabei die supported_rates nicht vernünftig zu den basic_rates gesetzt, was unschön ist und wodurch einige Probleme entstehen können.
Also require_mode tut nichts anderes, als die basic_rate’s setzen. Damit werden zwar die 802.11b Geräte ausgeschlossen, aber der AP sagt, er könne noch 802.11b als mögliche Datenraten. Setzt mal supported_rates, verschwinden die langsamen Datenraten aus der Liste der unterstützten Datenraten.
Ich setze require_mode nicht, da sonst die mit basic_rate gesetzten Datenraten überschrieben werden.
Quelle: https://github.com/freifunk-gluon/gluon/pull/467#issuecomment-137417111
2 „Gefällt mir“
Hallo zusammen, leider schaffe ich es momentan nicht regelmäßig hier rein zu schauen. Finde die Diskussion und das Thema (nicht nur wegen meiner BA) sehr interessant.
Bei meinen Recherchen habe ich oft das Best Practice gefunden alle Datenraten unterhalb 24 abzuschalten. Diese Liste zeigt weshalb:
- 802.11b DBPSK 1,0
- 802.11b DQPSK 2,0
- 802.11b DQPSK 5,5
- 802.11b DQPSK 11,0
- BPSK 6,0
- BPSK 9,0
- QPSK 12,0
- QPSK 18,0
- 16-QAM 24,0
- 16-QAM 36,0
- 64-QAM 48,0
- 64-QAM 54,0
Es würde sich also lohnen bei folgenden Sprüngen ein Vorher / Nachher zu beobachten: 6, 12, 24
Hallo - gibt*s ein finales Fazit nach ~10 Wochen „ohne B“?
Die Übertragungsqualität im Mesh ist bedeutend besser geworden, dafür haben wir deutlich mehr reboots.
Die reboots lagen aber soweit ich das beurteilen kann an 2016.2.3, denn die 2016.2.4 knoten haben sehr gute uptimes.
Insgesamt also enorm empfehlenswert, der seewt spot könnte aber tatsächlich noch bei etwas höheren Datenraten liegen, eventuell hat @adorfer schon Daten dazu gesammelt.
1 „Gefällt mir“