[Wien] [Discuss] Solarinsel

[Markus Kittenberger]

2011/9/1 Erich N. Pekarek <(spam-protected)>
>
>  Client- und Masterinterface auch, wenn das im ersten Moment sinnwidrig
> erscheinen mag -
>
 und warum willst du das tun?
(siehe auch unten bzgl "gesondert generieren")

>  allerdings selektiv.
>
d.h. nur bridgen damit es für den olsrd wie ein interface aussieht?
jedoch nit zwischen den interfaces forwarden?

> 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.
>
> 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 geh davon aus dass sie sich bei gleichen traffic gleichviel stören,..

jedoch da die oslrd pakete für jeden nachbarn nun einzeln gesendet werden
muessen, gibts mehr gelegenheiten zum stören,..

>     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,
>
und das ist das problem!

> aber eben nicht für zwei Devices gesondert generiert werden.
>
was (cpumaessig) nit schlimm ist

denn olsrd erzeugt bei einzelnen interfaces ja auch weniger traffic /jedoch
nit weniger als bei nem broadcast an alle!(
und dadurch wieder weniger cpuload beim nachbar , als wenn es gebridged
wäre,
weil er bei einzelnen interfaces den jeweiligen/m nachbarn nur erzählt was
der/die noch nit definitiv wissen,..


> 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
>
ein adhoc client welche einen link nicht zum routen verwendet, stört
eigentlich nit.
d.h. selektiv trennen (= nicht verwenden) macht der olsrd eh schon,..

und so die Linkqualität und die Datenrate des Nodes verbessern.
>
diese (datenrate) ist sowieso je nach nachbar unterschiedlich,..

>   (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.
>

trotzdem erzeugt batman mehr traffic als olsrd *G (und braucht mehr cpu, und
routet schlechter, usw,..)
(zumidnest was das afair das ergebnis eines jeden battle meshes so far)

und oslrd koennte deutlich weniger trafifc erzeugen, wenn wir die plaene
dafuer mal endlich umsetzen wuerden *G

>
>
> 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.
>
aber ob man soweit teilen soll, dass über das selbe übertragungmedium zig
VAPs gleichzeitig herrschen sollen!?

und jein, jedes device muss andere pakete zumindest zur kenntnis nehmen,
also die recht lange preambel und mac-header lesen, der unterschied ist nur
ob dann noch 20 byte ethernet header auch noch dazukommen oder nit,..

>  (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.
>
die cpu bekommt die pakete eh nit,.. (wenn es keine broadcasts sind)

und ob ein dertiges setup inkl olsrd cpuload irgendwas spart ist recht
unsicher, kann leicht auch anders kommen, vorallem wenn du mit bridges
sparen willst,..

lg Markus

p.s. mein resumee der einzige wirkliche vorteil wäre das non adhoc fähige
geräte funktionieren würden
ansonsten befürcht ich unterm strich nur mehr oder weniger grosse
nachteile,..
und klarerweise viel arbeit, viel bugs, bis es mal überhaupt funktioniert,..
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20110901/98453574/attachment.htm>