[Berlin-wireless] Zusammenhang basic-rate, Durchsatz; Optimierung der LQ Bestimmung, mal testen?

Di Mär 14 16:29:53 CET 2006

Marco,

das trifft schon die richtige Wifi-Tonart :) Zwischen "muesste eigentlich" 
und "geht tatsachlich" gibt's da ja so feine Unterschiede. Hab' Dank fuer 
den Test und den Vorschlag.

Generell waere ich eher dafuer, bei den niedrigeren Raten das "b" irgendwie 
wegzuzaubern. Mit einer festen Rate geht es ja auch nicht nach oben und die 
naechste Update-Runde mit Multcast soll ja nicht gleich von vorneherein 
gebremst starten. Freies-Radio-Berlin wird es aber nur mit schnellen 
Multicast geben (-> das dauert aber noch).

Aber fuer erste Tests kann man das durchaus mal auf einen festen Wert 
einstellen. Und es sollte wenigstens geguckt werden, wie das mit MadWifi 
geht -> sonst haengen wir die Cubes und eine ganze Reihe von Linux-PCs ab. 
One more on the todo list.

Grusz, Sven-Ola

"Marco Tidow" <martidow at cs.tu-berlin.de> schrieb im Newsbeitrag 
news:20060314151919.Q15666 at zappa.local...
> Hi und moinmoin,
>
> obwohl das Folgende hier und da schonmal angesprochen wurde, gibt es
> wohl m.W.n. bislang keine "offizielle Linie" ;-) bzw. schreibe ich dies,
> um meine eigenen Unklarheiten zu beseitigen.
>
> Das Versenden von beacons und broad-/multi-casts geschieht bei wlan mit 
> einer
> anderen bitrate als der für unicasts, für Nutzdaten von Knoten-zu-Knoten
> verwendeten.
> Auch RTS-handshake, preamble- und ACK-, also die gesamte 
> "frame"-Kommunikation
> läuft mit der niedrigeren basic-rate; nur die "Nutzdaten" werden mit der 
> vollen
> zwischen zwei nodes direkt möglichen bitrate, also z.B. 54Mbit im B+G mode
> verschickt.
>
> [Vergl. : 
> http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.mac.html ]
>
> Beim broadcom läßt sich die basic-bitrate per "wl mrate" anzeigen,
> bzw. per "wl mrate 11" z.B. fest auf 11Mbit setzen.  Meiner Beobachtung 
> zu-
> folge ergab sich damit eine merkbar bessere, "flüssigere" Kommunikation
> zwischen den Knoten am Boxhagener Platz, auch und grade in den 
> Abendstunden,
> wenn dort die Luft auf 2,4GHz "brennt" (>20 wlan's, viel traffic auch auf
> störend nahen Kanälen).
>
> default-mäßig steht mrate auf "auto", was den interfaces i.d.R. die Wahl
> der basic-rate zwischen 1, 2 und 11Mbit läßt (b oder b/g mode).  Offenbar
> reicht aber auch nur ein mieser Nachbar-link, um die mrate auf 1Mbit
> einzufrieren.  Was ich vorschlage, ist eine Art "Funk-chauvinismus", aber 
> mit
> der Option, ihn zu abschalten, in 3D eher selten:
>
> Meinem Verständnis nach heißt "mrate 11Mbit" u.a.,
>  - die olsr-broadcast packets und der gesamte RTS-Kram verbrauchen weniger
>    der Luft-Bandbreite
>  - bei 11Mbit arbeiten die Radios mit einer niedrigeren Impuls-Sendestärke
>    als bei z.B. 1Mbit (EIRP gibt IMHO den gemittelten Wert über die Zeit 
> an,
>    was hieße, entweder darf man wenige fette Impulse oder viele kleine
>    rauspusten, um dieselbe max. EIRP einzuhalten)  korrekt???
>
> Mit einer höheren, fest auf 11Mbit eingestellten mrate,
>  - können b-only interfaces ohne Probleme mitspielen, empfangen die 11Mbit
>    broadcast's etc. ohne Probleme solange die Funkstrecke es eben her gibt
>    (getestet mit prism2 und atmel, unter Linux und win$)
>  - reduziere ich Störungen entfernter Knoten durch fette 1Mbit broadcast's
>    solcher Stationen, mit denen sich nicht wirklich schnell komunizieren 
> läßt
>    (grade jetzt bei Schnee zeigen sich die drolligsten link-Wege...)
>  - ergibt sich ein genaueres Bild des realen Nutz-packet-loss bei
>    der LQ-Bestimmung und miese links fallen aus der routing-table eher 
> raus
>
> und grenze umgekehrt entferntere Stationen ohne 11Mbit-fähige 
> Zwischen-links
> komplett aus ( :-( ).  Hier läßt sich immerhin das günstigste Gegenüber 
> mit
> niedrigerer basic-rate beibehalten, dessen Nachbarn nichtsdestotrotz mit 
> 11MBit
> laufen können.
>
> ABER:
> Betreibt man mehrere Knoten dicht nebeneinander, auf derselben Frequenz, 
> im selben
> logischen Netz (SSID), wo der eine z.B. den Nahbereich abdeckt und nur
> allen "Müll" der lokalen Nachbarn Antennen-mäßig wahrnimmt, und ein 
> zweiter
> mit Richtantenne nach jwd funkt, kriegt der mit der lokalen Antenne nicht 
> mit,
> wenn sein Weitverkehrs-Nachbar grade was mit dem großen Ohr hört, und 
> stört
> ggfs. dessen Empfang, weil er denkt, das Band ist frei.  Darauf mosert der
> Fernwirker mit NACK nach jwd.  und alle, der lokal-only, der Fernwirker 
> und
> "jwd" gönnen dem Band erstmal 'ne Auszeit.  Vermeiden lassen sich diese
> Kollisionen nicht, aber offenbar mindern.  Ähnlich der Fragmentierung auf 
> MAC-
> Ebene, verkürzt eine höhere basic-rate die versandten packets in der Luft,
> und reduziert damit das Zeitfenster, während dessen keine Störungen 
> passieren
> dürfen, die sonst eine Wiederholung des packets erfordern.
>
> Also kann es doch eigentlich nur von Vorteil sein, der "Verwaltung" etwas 
> Dampf
> zu machen, zumindest bei "lokal" funkenden Stationen, oder eben allen.
> Schon ersteres könnte die Balance solcher Nachbar-Konstellationen
> verbessern.
>
> Wie wäre es mit einer Erweiterung der config-Option "wl0_rateset" um 
> "ff_basicrate"
> im Drahtlos-Menü?
>
> e.g. in Pseudo-code:
>
> -------- vor Laden des wl.o -------------------
> MRATE="$(nvram get ff_basicrate)"   # "fix" for defaults, else "fix-2" for 
> 2Mbit
> case MRATE in
>  fix*)
>      nvram set wl0_rateset=all
>      MODE="$(nvram get wl0_gmode)"
>      MRATE="${MRATE#fix-}"; MRATE="${MRATE#fix}"
>      case MODE in
>        0|1)  [ -n "$MRATE" ] || MRATE=11;;
>          2)  [ -n "$MRATE" ] || MRATE=36;;
>      esac
>    *)
>      MRATE='auto'
>      ;;
> esac
> ------- nach ifup wifi ------------------------
> wl mrate "$MRATE"
>
> na ja, für'ne Probephase reicht im laufenden Betrieb auf den WRT's
>
> "wl mrate 11; wl ssid 'olsr.freifunk.net'"
>
> (prism2 unter Linux:  "iwpriv wlan0 basic_rates 7")
>
> Wirklich beurteilen läßt sich der Effekt einer fixen, höheren basic-rate 
> nur,
> wenn eine hinreichend große Nachbarschaft mitmacht.  Die meisten nodes 
> rund um
> den Boxhagener Platz sind bereits so eingestellt, inkl. der Schüssel 
> 104.130.1.14 .
>
> any comments?
> marco
>
>
> _______________________________________________
> Berlin mailing list
> Berlin at olsrexperiment.de
> https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin 

_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin