Ich werde jetzt mal in einer kleinen Wolke mit einer mcast_rate von 18000 testen, um zu schauen, ob das merklichen (positiven) Einfluss auf Airtime/möglichen Gesamtdurchsatz in (zu) eng vermaschten Wolken hat.
2 „Gefällt mir“
Vermutlich die in 802.11g spezifizierten Abstufungen, also: 54000, 48000, 36000, 24000, 18000, 12000, 9000, 6000, 5,500, 2000 und 1000
Hat der Test eigentlich nachvollziehbare/praxisrelevante Ergebnisse gebracht?
1 „Gefällt mir“
@adorfer
bin gerade bei einem anderen Recherche nochmal drauf gestoßen und würd gern wissen ob du da was neues weisst … spiel mit dem gedanken das bei einigen Wolken mal probeweise hoch zu setzen …
Wireless configuration [Old OpenWrt Wiki] sagt ja das du damit die mcast_rate von driver default (??) auf fixed whatever setzt.
(ich selber wollte evtl AP mode basic_rate und supported_rates setzen um die alle auf mind. 3 mbit oder ein multiple of 6 zu zwingen … und beobachten wie sich das verhält) → offtopic, nur zur info
Ich habe mehreres hochgesetzt, sowohl die mcastrat, wie auch nach dem Request von Ruben für die basic+russported-rate)
@adorfer … kannst du das genauer sagen, was hast du wo geändert, manuell für einzelne nodes ala
uci set wireless.client_radio0.basic_rate="5500 6000 9000 11000 12000 18000 20000 24000 30000 36000 40000 42000 44000 48000 50000 51000"
oder in der FW direkt … und wenn du die je hochsetzt … wie sind die Erfahrung, verhindert das dann wirklich das clients sich mich 1Mbs verbinden …
(und auch die mcast rate … ich geh davon aus das das unproblematisch geklappt hat)
Wir haben hier die mcast_rate vor einem Jahr auf 12000. hochgesetzt. Hat gefühlt (nicht gemessen) die Performance (unsere Vermutung war auch wg. Airtime) verbessert.
In folge sind ein paar Meshes abgerissen aber die waren vorher eh kaum brauchbar.
1 „Gefällt mir“
habe sehr gute erfahrung mit mcast rate 18000 gemacht, oder auch 24000 wenn die Knoten nah genug beieinander stehen. In knapp bemessenen Szenarien (weite Strecken) kann man das auch nach unten setzen
Aber Achtung : mcast 20000 gibt es nicht , bspw. da verliert man dann den ibss0 uplink (den Fehler hab ich hier gemacht)
hier ein kleiner horst screenshot
Kann es sein, dass z.B. die mcast_rate=12000 den wert nicht auf mindestens 12MBit sonder genau 12 MBit setzt?
Also, wenn man diesen optionalen Wert gar nicht seetzen würde, dann würde man zwar niedrigere Verbindungen erlauben, aber auch schnellere?
Also Vorschlag: mcast_rate wert weg lassen
@rubo77 bist du sicher das ibss0 verbindungen dann zustande kommen, wenn mcast nicht gesetzt ist, und wenn ja, das die nicht zwangsweise auf 1 Mbit dümpeln?
Du kannst es auch auf 18000 setzen.
Wichtig ist nur, dass Du einen „prinzipiell möglichen Wert“ exakt angibst.
„14500“ funktioniert also nicht.
[info-freiburg] wir fahren mit 18000 ganz gut, damit bekommen wir auch recht gut raten an dichten Flüchtlingsunterkünften hin, wo wir sogar noch höhere Raten andachten, aber verworfen haben - und es für ein unisono 18000 kbit entschieden haben.
1 „Gefällt mir“
Ich denke, das sollte man mal ein für alle mal klären. Wir wollen natürlich mindestens 12MBit aber auch schnellere Verbindungen erlauben.
Vielleicht besser direkt im Gluon issue diskutieren: gluon-core: make wifi rates configurable by kb-light · Pull Request #810 · freifunk-gluon/gluon · GitHub
Das große Problem in gut frequentierten APs ist die Airtime (oder deren Mangel)
Ein Dutzend Clients bei 2MBit/s-Rate (ohne Traffic!), die am Ladegerät „schlafen“ und nur bei Twitter, WhatsApp etc ideln: Das verbraucht mehr als ein YT-HD-Stream.
2 „Gefällt mir“
@rubo77 die Rechnung ist ziemlich einfach - tausche Reichweite gegen mesh-bandbreite . Wenn du in dichten Installationen vor allem hinter Meshenden Knoten Bandbreite brauchst - willste eine höhere Mcast Rate. Weil die das zu deinem uplink dann limitiert.
12000 ist als default reasonable - weil dir das „Bandbreite“ und Reichweite gibt.
Hab das nie ausprobiert, aber mit einer ungesetzten Mcastrate (=1Mbit) dürftest du an einem meshenden Knoten auch nicht mehr wie 1 Mbit weg schaufeln können und dann ist der Kanal da voll. (da du ja auch selber mit dem meshenden Knoten sprichst, vermutlich eher so um die 30 Mbit) musste das noch mit einberechenen … und das Grundrauschen (batman Netz Traffic).
… kannst du gern mal ausprobieren, 2 Knoten - davon einer uplink, beiden eine MCastrate von 1Mbit, dem meshenden knoten eine andere ssid geben - wifi neu starten - und dann mal messen was du da so durchbekommst, bin gespannt.
… soweit mein verständnis von der MCAST Rate.
1 „Gefällt mir“
bevor hier noch leute diese teils falschen Aussagen glauben, verlinke ich besser mal die Ausführungen von @anon75826926 zum Thema:
1 „Gefällt mir“
Hallo.
Nur für mich zum Verständnis: wird eigentlich der komplette IBSS-Meshverkehr per Multicast abgewickelt? Oder werden Unterscheidungen gemacht (z.B. Baken Multicast, Daten Unicast)?
Und wie verhält es sich eigentlich bei 11s?
Gruß Christian
@DL3DCF die Antwort lieferte Rotanid / neoraider
Full Quote
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.
Aus dem ersten Absatz wird mir klar, dass der Mesh traffic einen Multicast Anteil hat, sodass sich das wohl lohnen wird, die mcast_rate zu erhöhen. Mehr aber auch nicht. Wenn Du @fuzzle damit sagen willst, dass der Anteil 100% ist, dann halten wir das mal so fest.
Mir fehlt da aber auch noch etwas der Hintergrund.
wie lange wollt ihr eigentlich noch auf der Tatsache herumreiten, dass im Betreff nur „mcast_rate“ steht?
Soll ich das mal anpassen?
Oder wollt ihr lieber einen neuen Thread aufmachen zu supported_rates und basic_rate?
http://gluon.readthedocs.io/en/v2016.2/user/site.html
Additionally it is possible to configure the supported_rates and basic_rate
of each radio. Both are optional, by default hostapd/driver dictate the rates.
If supported_rates is set, basic_rate is required, because basic_rate
has to be a subset of supported_rates.
The example below disables 802.11b rates.
ap requires a single parameter, a string, named ssid which sets the
interface’s ESSID.
mesh requires a single parameter, a string, named id which sets the mesh id.
ibss requires two parametersr: ssid (a string) and bssid (a MAC).
An optional parameter vlan (integer) is supported.
Both mesh and ibss accept an optional mcast_rate (kbit/s) parameter for
setting the default multicast datarate.
wifi24 = {
channel = 11,
supported_rates = {6000, 9000, 12000, 18000, 24000, 36000, 48000, 54000},
basic_rate = {6000, 9000, 18000, 36000, 54000},
ap = {
ssid = ‚entenhausen.freifunk.net‘,
},
mesh = {
id = ‚entenhausen-mesh‘,
mcast_rate = 12000,
},
ibss = {
ssid = ‚ff:ff:ff:ee:ba:be‘,
bssid = ‚ff:ff:ff:ee:ba:be‘,
mcast_rate = 12000,
},
},