mögliche Werte für "mcast_rate"

Was sind dennn mögliche Werte abgesehen von 12000 und 6000?

Weitere Fragen dazu:
Werden die OGM-Pakete eventuell „fix“ auf der mcast_rate abgestrahlt, auch wenn alle Knoten schneller angebunden sind in der Nähe?

Oder welchen Vorteil brächte es, die Zahl der Links mittels einer höheren Rate zu verringern, um so „unnütze“ Links gleich loszuwerden und so auf die verbleibenden weniger Airtime auf ineffektive Links zu verbraten.

Oder hilft es gar nicht?

Hintergrund sind Szenarien mit 6-10 Routern im Wifimesh, die in Total nicht über 10MBit/s m Stundenmitel kommen, selbst bei Linkqualität >90% auf den belasteten Strecken.

1 Like

ich glaub du musst mehr sagen welche Werte woher du gerade meinst,
weil ich verstehe gerade mcastrate als alle 12 oder alle 6 Sekunden geht die batman-adv akete rum um die originator table neu zu schreiben - aber das meinst du vermutlich nicht. bzw. ich versteh die Frage nur halb.

Das wäre das Originator-Interval.
Mir geht es um die mcast_rate, die in der site.conf spezifiziert wird.

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 Likes

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 Like

@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 Like

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 Like

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 Likes

@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 Like

bevor hier noch leute diese teils falschen Aussagen glauben, verlinke ich besser mal die Ausführungen von @neoraider zum Thema:

1 Like

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