<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hallo!<br>
<blockquote
cite="mid:CAKNLPNK+NqTHo73nbDZm6U5SsjkL627H3CyAwRNquegHjzAYmA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>das ist vorerst egel olsr und routing als auch ap/client
mode legt keinen wert daruaf was für ips konfiguriert sind,..</div>
<div>(insofern koennen wir prinzipiell weiter chaotisch ips
konfigurierern (-;)</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">Bridges.<br>
</div>
</blockquote>
<div>bridge? </div>
<div>was willst zambridgen?</div>
</div>
</blockquote>
Client- und Masterinterface auch, wenn das im ersten Moment
sinnwidrig erscheinen mag - allerdings selektiv.<br>
<br>
<blockquote
cite="mid:CAKNLPNK+NqTHo73nbDZm6U5SsjkL627H3CyAwRNquegHjzAYmA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> 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.</div>
</blockquote>
<div>sicher?</div>
<div>die VAPs laufen auf der gleichen frequenz, und stören sich
wohl mindest genausogerne untereinander wie die adhoc links.</div>
</div>
</blockquote>
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.<br>
Ob dadurch die Anzahl der gesendeten Pakete steigt oder, ob es sich
um eine Art Zeitmultiplex handelt, ist mir selbst nicht klar.<br>
<br>
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.<br>
<br>
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.
<blockquote
cite="mid:CAKNLPNK+NqTHo73nbDZm6U5SsjkL627H3CyAwRNquegHjzAYmA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im">
<blockquote type="cite">
<div class="gmail_quote">
<div>ich denk auf jedem wifi soviel VAPs wie geht, ist
imho schlechter als adhoc</div>
<div>(zumindest bzgl olsr traffic)</div>
</div>
</blockquote>
</div>
Was erst noch zu zeigen wäre. (Im Falle einer Brigde bspw.
wird das nicht eintreten).<br>
</div>
</blockquote>
<div>wieso soll eine bridge das verhindern?</div>
<div><br>
</div>
<div>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,..</div>
</div>
</blockquote>
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.<br>
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.<br>
<br>
<blockquote
cite="mid:CAKNLPNK+NqTHo73nbDZm6U5SsjkL627H3CyAwRNquegHjzAYmA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> <small><small><small> (wobei
es mich brennend interessieren würde, ob
beispielsweise BATMANd im der Realität wirklich das
Broadcastproblem gegenüber olsr effektiv senkt.)</small></small></small></div>
</blockquote>
<div>inwiefern sollte er das?</div>
</div>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:CAKNLPNK+NqTHo73nbDZm6U5SsjkL627H3CyAwRNquegHjzAYmA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>afair sendet er doch ebenso boadcasts für seinen
protokolltraffic</div>
<div>(und mit üblichen settings mehr davon als olsrd es tut)</div>
</div>
</blockquote>
In den ersten Versionen soll das noch zutreffend gewesen sein - ob
das aktuell noch so ist?<br>
<br>
<blockquote
cite="mid:CAKNLPNK+NqTHo73nbDZm6U5SsjkL627H3CyAwRNquegHjzAYmA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im">
<br>
</div>
<div class="im">
<blockquote type="cite">
<div class="gmail_quote">
<div>aber AP mode und powersave gibts eigenltich nit</div>
</div>
</blockquote>
</div>
Das nicht, aber der Node muss dann nicht jedes
Schrottsignal, das bei ihm ankommt verarbeiten</div>
</blockquote>
<div>der node verarbeitet eh nur broadcasts,..</div>
<div>und das wifi muss weiterhin jedes schrottsignal auf seiner
frequenz soweit "lesen" um zu wissen das es nicht für es
gedacht ist,..</div>
</div>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:CAKNLPNK+NqTHo73nbDZm6U5SsjkL627H3CyAwRNquegHjzAYmA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>(weiters ists idr stromverbrauchmaessig voellig egal, ob
nur rauschen oder "lesbare" signale daherkommen)</div>
</div>
</blockquote>
Vernachlässigbar. Dennoch - wenn es auf schwachen Devices CPU spart,
schadet es ja auch nicht.<br>
<br>
<blockquote
cite="mid:CAKNLPNK+NqTHo73nbDZm6U5SsjkL627H3CyAwRNquegHjzAYmA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">, wodurch die Leistung
vernachlässigbar sinkt. (Was ebenfalls noch zu testen wäre).
Es reicht ja schon, wenn die Luft ein bisserl sauberer wird
;-)</div>
</blockquote>
<div>durch nicht empfangen wird die luft ja nit sauberer,.</div>
</div>
</blockquote>
Aber durch nicht antworten müssen (Herumplärren...). Eine moderierte
Diskussion ist meist verständlicher als wirres Herumplaudern.<br>
<br>
<blockquote
cite="mid:CAKNLPNK+NqTHo73nbDZm6U5SsjkL627H3CyAwRNquegHjzAYmA@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>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,.. <br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
Für jeden Hinweis dankbar.<br>
<br>
Erich<br>
</body>
</html>