<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Am 2011-09-01 09:36, schrieb Markus Kittenberger:<br>
<blockquote
cite="mid:CAKNLPNJmMBJbQ6vcWyXuLgMr_dtboz8gYGqW1hW_xH5yvQZ1Ug@mail.gmail.com"
type="cite">
<div class="gmail_quote">2011/9/1 Erich N. Pekarek <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:erich@pekarek.at" target="_blank">erich@pekarek.at</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Hallo!<br>
<div>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Ethernet port und Treiber Support (-> ad-hoc mode
waere nett ;-) )<br>
<br>
a.<br>
</blockquote>
</div>
Nett ja, aber Ad-hoc-Mode wird möglicherweise überschätzt.</blockquote>
<div>partly ACK</div>
<div>wie hast du dir ap/client setup denn genau vorgestellt?</div>
</div>
</blockquote>
<br>
Ein Router im VAP-Mode mit einem Master und mehreren Clients (einer
pro Partner), IP-Setup statisch, Bridges.<br>
<br>
Jeder Master hat eine eigene ESSID. Bei Knoten mit bis zu drei
Partnern entstehen so separate Verbindungen. ()<br>
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.<br>
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.<br>
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.)<br>
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?)<br>
<br>
<blockquote
cite="mid:CAKNLPNJmMBJbQ6vcWyXuLgMr_dtboz8gYGqW1hW_xH5yvQZ1Ug@mail.gmail.com"
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>
Was erst noch zu zeigen wäre. (Im Falle einer Brigde bspw. wird das
nicht eintreten).<br>
<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><br>
<br>
<blockquote
cite="mid:CAKNLPNJmMBJbQ6vcWyXuLgMr_dtboz8gYGqW1hW_xH5yvQZ1Ug@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<div>aber es erlaubt halt auch non adhocfähige geräte
inzubeziehen,..</div>
</div>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:CAKNLPNJmMBJbQ6vcWyXuLgMr_dtboz8gYGqW1hW_xH5yvQZ1Ug@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>ein aspekt darf man aber nit vergessen,.. (da wir ja noch
im solarnode thread sind *G)</div>
<div>client mode ist nett (weil powersave problemlos
funktinoert,.)</div>
</div>
</blockquote>
Ack.<br>
<blockquote
cite="mid:CAKNLPNJmMBJbQ6vcWyXuLgMr_dtboz8gYGqW1hW_xH5yvQZ1Ug@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>aber AP mode und powersave gibts eigenltich nit</div>
</div>
</blockquote>
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 ;-)<br>
<br>
<blockquote
cite="mid:CAKNLPNJmMBJbQ6vcWyXuLgMr_dtboz8gYGqW1hW_xH5yvQZ1Ug@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;">
Ad Ethernet-Port:<br>
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.<br>
</blockquote>
<div><br>
</div>
<div>nur dann ist der effizienzvorteil des smartphones idr
dahin,.. <br>
</div>
</div>
</blockquote>
Eh klar...<br>
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.<br>
<br>
<blockquote
cite="mid:CAKNLPNJmMBJbQ6vcWyXuLgMr_dtboz8gYGqW1hW_xH5yvQZ1Ug@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>usb zeugs braucht leider garnitsowenig strom,..</div>
</div>
</blockquote>
Kommt auf das jeweilige Zeugs an.<br>
<br>
<blockquote
cite="mid:CAKNLPNJmMBJbQ6vcWyXuLgMr_dtboz8gYGqW1hW_xH5yvQZ1Ug@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>und hubs erst recht (falls man statt nem usb-ethernet
lieber gleich etliche usb-wifis anschliessen will)</div>
</div>
</blockquote>
<br>
Das würde ich ja nur beim USB-Server-Projekt tun, wo der Strom ja
zumindest über PoE kommt.<br>
<br>
<blockquote
cite="mid:CAKNLPNJmMBJbQ6vcWyXuLgMr_dtboz8gYGqW1hW_xH5yvQZ1Ug@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<div>denn vorallem mehrere router/smartphones per switch und
ethernet zu verbinden, ist sowieso extrem ineffizient,..</div>
</div>
</blockquote>
<br>
Spricht wieder für den AP-Mode mit VAP-Interface für die Wartung.<br>
<br>
SG<br>
Erich<br>
</body>
</html>