<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Hallo!<br>
<br>
Am 2013-12-06 02:06, schrieb Petr Koval:<br>
</div>
<blockquote cite="mid:52A122FE.1010507@gmail.com" type="cite">Erich
N. Pekarek schrieb:
<br>
<br>
[..]
<br>
<br>
<blockquote type="cite">Könntest Du das Problem bitte mit wenigen
Worten etwas präziser darstellen?
<br>
...<br>
</blockquote>
Bei Verschlechterung des Empfang am Brenner durch Störungen, hört
die Master/Client Kommunikation
<br>
für manche Clients völlig auf (bei 4-5 Clients, somit werden
danach nunmehr 2-3)
<br>
obwohl diese für die Adhoc Kommunikation immer noch
<br>
bei 5-10 MBit/s läuft (bei 6-8 Adhoc Partnern).
<br>
Ich sehe die kritische Situation bei schlechten Bedingungen, wann
Adhoc noch geht und gar nicht so schlecht,
<br>
obwohl Master/Client zu so einem Augenblick überhaupt nicht für
manche Partner geht.
<br>
Nur bei sehr guten Bedingungen zeigt sich Master/Client gegenüber
dem Adhoc/Adhoc vorteilhaft, wie etwa gerade jetzt.
<br>
</blockquote>
Das ist nicht nachvollziehbar. Von welchen Stationen sprichst Du
konkret, in welchem Zeitraum, ...<br>
Um zu debuggen, sind ein paar konkretere Informationen erforderlich
- hast Du tatsächlich Zugriff auf 6-8 Adhoc-Partner des Brenner NW?<br>
<br>
<blockquote cite="mid:52A122FE.1010507@gmail.com" type="cite">
<blockquote type="cite">Dass beide Modi zusammen nicht das Optimum
sind, sondern eher ein Workaround, weißt Du ja.
<br>
Dass die WRTs wegen eines Firmwarebugs nicht mit dem Client-Mode
funktionieren, ist aus meiner Sicht der einzige Grund, warum
Adhoc dort überhaupt noch läuft. Die Umstellung wird aber nicht
klappen, wenn das Mischkonzept zur Gewohnheit wird.
<br>
<br>
</blockquote>
Ich benutze Brenner auch nicht als primären Weg, sondern lediglich
als Verbindungsbackup. Als Primär wollte ich den für mich am
besten "io" nehmen, der zeitlang sehr gut lief, allerdings in der
letzten Zeit äusserst schlecht wurde, nach dem er
<br>
jetzt auch mit oa12 kommuniziert. Dennoch wurde ich auch bei guten
Verbindungsverhältnissen oft wie von io selbst wie von brenner als
default Route genommen (!)
<br>
und der gesammte brenner Traffic lief bei nur 5-10 MBit/s über
mich, entweder direkt über mein Tunnel oder über ley23 seins.
<br>
</blockquote>
Dann solltest Du parallel dazu vielleicht am Debugging an Deiner
Verbindung zu io arbeiten?<br>
<blockquote cite="mid:52A122FE.1010507@gmail.com" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<br>
ich fahre beide Modi gleichzeitig (xbrenner(C).ley21)
<br>
so betrifft mich es nicht unbedingt schmerzhaft
<br>
</blockquote>
Ist das sinnvoll? Oder reduziert das nicht eher unnötig Airtime
für alle teilnehmenden Stationen?
<br>
Ich halte das für kein Setup, das die Redundanz verbessert,
sondern eher für das Gegenteil davon.
<br>
<br>
</blockquote>
sinnwoll ist es meiner Meinung nicht, aber das ist im Prinzip
Master/Client Betrieb genauso wenig
<br>
ausser bei dedicated 1 zu 1 peers bei voller Bandbreite, aber da
ist dann auch kein adhoc bzw. multilink im Spiel
<br>
</blockquote>
Naja, dazu gibt es einen wissenschaftlichen Aufsatz, der Deiner
Behauptung nicht ganz gerecht wird:<br>
<a class="moz-txt-link-freetext" href="http://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf">http://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf</a><br>
Von dedizierten Verbindungen ist dort nicht die Rede, sondern man
ersetzt Adhoc durch Master und Client auf derselben (E)SSID (auf
demselben Kanal) [mit ein paar Tricks]. Im Ergebnis ist das sogar
performanter als Adhoc.<br>
<br>
Mischbetrieb ist dagegen <b><i>auf Dauer</i></b> keine gute Idee -
als Workaround für gewisse Symptome funktioniert er zwar, senkt aber
Beobachtungen zufolge die Gesamtperformance.<br>
<blockquote cite="mid:52A122FE.1010507@gmail.com" type="cite">
<blockquote type="cite">
<blockquote type="cite">hätte ich dagegen kein Adhoc und hätte
ich nur Client/Master Antrieb
<br>
dann leider doch
<br>
</blockquote>
Siehe oben. Dir ist schon bewusst, dass Brenner NW momentan 9
Linkpartner, davon 4 auf dem Master, 5 über Adhoc hat und bis
zuletzt 14 assoziierte WLAN-Stations zu sehen waren - und er
damit zu den am meisten beschäftigten Devices in diesem Netz
gehört?
<br>
<br>
</blockquote>
Ich erreiche als Adhoc Partner dennoch mehr durchsatz in beide
Richtungen mit Brenner als ein Client am Master, auch dann wenn es
laut LQ/NLQ/ETX eigentlich umgekehrt sein sollte.
<br>
</blockquote>
Im Master/Client-Mode sind auch OLSR-Pakete durch RTS/CTS
abgesichert - d.h. die ETX beschwindelt Dich. Bei schlechten
Verbindungen - und da richte Dich bitte nach der SNR und den CRCs -
sorgt das für einen zusätzlichen Konsum an Airtime. Unter Umständen
wäre es sinnvoll, den RTS-Schwellenwert in dem Fall zu löschen. Am
Brenner selbst geht das schwer, da er sonst im Adhoc-Mode sonst in
die Knie geht.<br>
<br>
<blockquote cite="mid:52A122FE.1010507@gmail.com" type="cite">Gleichzeitigen
Master habe ich nur deshalb, da vorgesehen ist den Adhoc auf dem
NW Brenner komplet auszuschalten und nur auf dem Master Betrieb zu
verbleiben.
<br>
</blockquote>
Was so bald nicht passieren wird, außer es verschwinden alle
WRTs/Buffalos über Nacht aus dem Netz oder werden mit neuerer
Firmware ausgestattet.<br>
Eine Firmware, die eine Mischung aus Attitude Adjustment
(stable/brcm47xx) und der Freifunk-Firmware wäre, könnte ein Ansatz
sein. <br>
Dazu nimmt man eine Openwrt AA, entfernt ein paar Abhängigkeiten,
ersetzt iproute2 durch busybox-ip, modifiziert das Paket
"base-files" (zwecks Initialisierung, entfernt netifd und Co) soweit
bin ich schon einmal... fertig ist das noch länger nicht - ich
könnte Hilfe gebrauchen.<br>
<br>
<blockquote cite="mid:52A122FE.1010507@gmail.com" type="cite">
<blockquote type="cite">Den OLSR-LQ-Werten zufolge haben wir
wieder ein Ungleichgewicht zwischen Senden und Empfangen: NW
hört wieder einmal schlechter als er
<Seitenhieb>"plärrt"</Seitenhieb>.
<br>
</blockquote>
Auf dem Master sollte es laut der Anzeige so sein, ist es aber
nicht. Zumindest in Verbindung mit mir definitiev nicht. Zumindest
schaft es Brenner immer noch mehr Daten von mir zu Empfangen
<br>
als ich von ihm.</blockquote>
In welchem Modus denn?<br>
Wie schaut die CRC-Statistik Deines WLAN-Treibers aus?<br>
<blockquote cite="mid:52A122FE.1010507@gmail.com" type="cite"> Aber
das ist auch nich nötig, wenn die meiste Datein zu mir nach wie
vor von Tunnel und nicht von Brenner kommen. Leider auch von
Funkfeuer IPs, nicht unbedingt
<br>
aus dem Internet.
<br>
</blockquote>
...<br>
<blockquote cite="mid:52A122FE.1010507@gmail.com" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<br>
<a class="moz-txt-link-freetext" href="http://xbrennerc.ley21.wien.funkfeuer.at/cgi-bin/luci/freifunk/olsr/neighbors/">http://xbrennerc.ley21.wien.funkfeuer.at/cgi-bin/luci/freifunk/olsr/neighbors/</a>
<br>
<a class="moz-txt-link-freetext" href="http://nordwestm.brenner.wien.funkfeuer.at/cgi-bin/luci/freifunk/olsr/neighbors">http://nordwestm.brenner.wien.funkfeuer.at/cgi-bin/luci/freifunk/olsr/neighbors</a>
<br>
</blockquote>
<br>
</blockquote>
<br>
</blockquote>
LG<br>
Erich<br>
</body>
</html>