[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