[Wien] [Discuss] Solarinsel
Erich N. Pekarek
(spam-protected)
Do Sep 1 12:58:05 CEST 2011
Hallo!
> das ist vorerst egel olsr und routing als auch ap/client mode legt
> keinen wert daruaf was für ips konfiguriert sind,..
> (insofern koennen wir prinzipiell weiter chaotisch ips konfigurierern (-;)
>
> Bridges.
>
> bridge?
> was willst zambridgen?
Client- und Masterinterface auch, wenn das im ersten Moment sinnwidrig
erscheinen mag - allerdings selektiv.
> Ein Vorteil wäre, dass die somit quasi-dedizierte Verbindungen
> zustande kommen, was der Stabilität und dem Durchsatz der Links
> sicherlich zu Gute kommt.
>
> sicher?
> die VAPs laufen auf der gleichen frequenz, und stören sich wohl
> mindest genausogerne untereinander wie die adhoc links.
Wie funktioniert ein virtueller Access Point wirklich? Soweit ich weiß,
ist das noch nicht standardisiert; es werden lediglich über ein
physikalisches Interface mehrere SSIDs ausgestrahlt.
Ob dadurch die Anzahl der gesendeten Pakete steigt oder, ob es sich um
eine Art Zeitmultiplex handelt, ist mir selbst nicht klar.
Das es sich aber nur um einen Sender handelt, können die Störungen schon
einmal nicht so hoch sein, wie wenn mehrere Geräte auf derselben
Frequenz funken.
Ich zweifle daher an der Theorie, dass sich VAPs eher stören als Devices
im Ad-Hoc Mode. Für widersprechende Theorien und Fakten wäre ich Dir
dankbar.
>
>> ich denk auf jedem wifi soviel VAPs wie geht, ist imho schlechter
>> als adhoc
>> (zumindest bzgl olsr traffic)
> Was erst noch zu zeigen wäre. (Im Falle einer Brigde bspw. wird
> das nicht eintreten).
>
> wieso soll eine bridge das verhindern?
>
> das problem ist das die selbe olsr message in jedem VAP einzeln
> gesendet werden muss , anstatt eines einzigem broadcasts an alle die
> es hören können,..
Wenn die Pakete nur für ein OLSR-Device generiert werden, müssen sie
zwar immer noch einzeln gesendet werden, aber eben nicht für zwei
Devices gesondert generiert werden. Das restliche Szenario erscheint mir
identisch zu sein. Die Übertragungswege für das OLSR bleiben dieselben,
nur habe ich im AP-Mode mehr Einfluss auf das Radio, kann Clients
selektiv trennen und so die Linkqualität und die Datenrate des Nodes
verbessern. Ich denke, dass das einen nicht zu vernachlässigenden Faktor
bildet und so auch zur Minderung von Broadcast beiträgt, wenn eine Route
unzuverlässiger wird.
Hinzu kommt eine menschliche Komponente, da der bisherige Automatismus
umgangen werden kann. Aber auch jetzt müssen Nodebetreiber miteinander
kommunizieren, um Probleme zu lösen.
> (wobei es mich brennend interessieren würde, ob beispielsweise
> BATMANd im der Realität wirklich das Broadcastproblem gegenüber
> olsr effektiv senkt.)
>
> inwiefern sollte er das?
Weil dieses Projekt sich konkret den Verbesserungen gegenüber OLSR
verschrieben hat und zumindest in der Beschreibung interessante Ansätze
dazu hat - insbesondere die Reduktion der Überhand nehmenden Broadcasts.
> afair sendet er doch ebenso boadcasts für seinen protokolltraffic
> (und mit üblichen settings mehr davon als olsrd es tut)
In den ersten Versionen soll das noch zutreffend gewesen sein - ob das
aktuell noch so ist?
>
>> aber AP mode und powersave gibts eigenltich nit
> Das nicht, aber der Node muss dann nicht jedes Schrottsignal, das
> bei ihm ankommt verarbeiten
>
> der node verarbeitet eh nur broadcasts,..
> und das wifi muss weiterhin jedes schrottsignal auf seiner frequenz
> soweit "lesen" um zu wissen das es nicht für es gedacht ist,..
Aber er muss nicht auf jedes Signal reagieren, wie es im Ad-Hoc-Mode
passiert, wenn ein Device mit derselben BSSID in der Nähe funkt. "Teile
und herrsche" ist sicherlich auch im Mesh kein schlechtes Prinzip.
> (weiters ists idr stromverbrauchmaessig voellig egal, ob nur rauschen
> oder "lesbare" signale daherkommen)
Vernachlässigbar. Dennoch - wenn es auf schwachen Devices CPU spart,
schadet es ja auch nicht.
> , wodurch die Leistung vernachlässigbar sinkt. (Was ebenfalls noch
> zu testen wäre). Es reicht ja schon, wenn die Luft ein bisserl
> sauberer wird ;-)
>
> durch nicht empfangen wird die luft ja nit sauberer,.
Aber durch nicht antworten müssen (Herumplärren...). Eine moderierte
Diskussion ist meist verständlicher als wirres Herumplaudern.
> durch das mit den VAPs vervielfachte senden der oslrd pakete, und evt
> auch mehr beacons für all die Vaps, wirds dann hingegen eher dreckiger,..
Sendet ein VAP wirklich mehr Beacons oder wird nur die On-Air-Time des
eingestellten Beacon Intervalls, geteilt, indem fallweise ein anderes
Beacon gesendet wird? Bei Funkprotokollen kann es ja sein, dass
fallweise ein Beacon nicht empfangen wird (Fehlertoleranz). Bei 333 bis
1000 Beacons pro Sekunde wird das vermutlich kein großes Problem sein,
wenn fallweise ein anderes Beacon ankommt. Das das Radio deswegen
schneller/öfter sendet, wage ich zu bezweifeln, kenne mich aber damit zu
wenig aus. Die häufige Beschränkung auf 5 VAPs liefert kein Indiz für
die eine oder die andere Annahme.
Für jeden Hinweis dankbar.
Erich
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20110901/fca94721/attachment.htm>
Mehr Informationen über die Mailingliste Wien