[Wien] [Discuss] Solarinsel

[Erich N. Pekarek]

Am 2011-09-01 09:36, schrieb Markus Kittenberger:
> 2011/9/1 Erich N. Pekarek <(spam-protected) <mailto:(spam-protected)>>
>
>     Hallo!
>
>         Ethernet port und Treiber Support (->  ad-hoc mode waere nett
>         ;-) )
>
>         a.
>
>     Nett ja, aber Ad-hoc-Mode wird möglicherweise überschätzt.
>
> partly ACK
> wie hast du dir ap/client setup denn genau vorgestellt?

Ein Router im VAP-Mode mit einem Master und mehreren Clients (einer pro 
Partner), IP-Setup statisch, Bridges.

Jeder Master hat eine eigene ESSID. Bei Knoten mit bis zu drei Partnern 
entstehen so separate Verbindungen. ()
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.
Das wäre aber noch im Detail zu testen. Bei den großen Nodes ist das 
freilich so keine Lösung, außer man verwendet ESSIDs wieder, sodass es 
zum Gruppieren von Links kommt.
Wobei allerdings die Annahme vorherrscht, dass ein großer Node in der 
Regel mehr "schlechtere" Clients haben wird als gleichwertige 
Linkpartner. D.h. er agiert gegenüber gleichwertigen Linkpartnern als 
Client und Slave und vermittelt via AP-Mode an die unzuverlässigeren 
Nodes, die Ihrerseits diese Struktur weitergeben. (das mag zwar nicht 
ganz egalitär sein, spiegelt aber die Realität besser wieder und geht 
auch diese Probleme ein.)
Die Details hängen vom jeweiligen Szenario ab. Stationen, die sowohl 
Ad-hoc als auch Master gleichzeitig unterstützen wären als  "Konverter" 
einzusetzen. (Bei den Special-Links tun wir das doch heute schon, oder?)

> 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).
  (wobei es mich brennend interessieren würde, ob beispielsweise BATMANd 
im der Realität wirklich das Broadcastproblem gegenüber olsr effektiv 
senkt.)

>
> aber es erlaubt halt auch non adhocfähige geräte inzubeziehen,..
Was sicher ein Hauptargument ist und auch ad-hoc-fähige Geräte schaffen 
meist nur ein Ad-Hoc-Netz und sonst kein weiteres. Das Problem wäre dann 
gegessen.

> ein aspekt darf man aber nit vergessen,.. (da wir ja noch im solarnode 
> thread sind *G)
> client mode ist nett (weil powersave problemlos funktinoert,.)
Ack.
> aber AP mode und powersave gibts eigenltich nit
Das nicht, aber der Node muss dann nicht jedes Schrottsignal, das bei 
ihm ankommt verarbeiten, wodurch die Leistung vernachlässigbar sinkt. 
(Was ebenfalls noch zu testen wäre). Es reicht ja schon, wenn die Luft 
ein bisserl sauberer wird ;-)

>     Ad Ethernet-Port:
>     PDAs konnten mittels Adapterkabeln als USB-Host agieren (z.b. Acer
>     n35). Smartphones werden sich wohl in ähnlicher Weise adaptieren
>     lassen, sofern die Stromversorgung passt. (Womit Thema 1
>     -Stromsparen-  wieder da wäre). USB-Ethernet-Adapter sind erhältlich.
>
>
> nur dann ist der effizienzvorteil des smartphones idr dahin,..
Eh klar...
IMO braucht der Solarnode als reiner Router auch nur ein Interface und 
kein Ethernet. Sowas stellt man an exponierten Orten auf, wo sonst 
nichts ist. Ergo reicht der Funk.

> usb zeugs braucht leider garnitsowenig strom,..
Kommt auf das jeweilige Zeugs an.

> und hubs erst recht (falls man statt nem usb-ethernet lieber gleich 
> etliche usb-wifis anschliessen will)

Das würde ich ja nur beim USB-Server-Projekt tun, wo der Strom ja 
zumindest über PoE kommt.

> denn vorallem mehrere router/smartphones per switch und ethernet zu 
> verbinden, ist sowieso extrem ineffizient,..

Spricht wieder für den AP-Mode mit VAP-Interface für die Wartung.

SG
Erich
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20110901/49925d39/attachment.htm>