Hallo!
Am 2013-12-06 02:06, schrieb Petr Koval:
Erich N. Pekarek schrieb:
[..]
Könntest Du das Problem bitte mit wenigen Worten etwas präziser
darstellen?
...
Bei Verschlechterung des Empfang am Brenner durch Störungen, hört die
Master/Client Kommunikation
für manche Clients völlig auf (bei 4-5 Clients, somit werden danach
nunmehr 2-3)
obwohl diese für die Adhoc Kommunikation immer noch
bei 5-10 MBit/s läuft (bei 6-8 Adhoc Partnern).
Ich sehe die kritische Situation bei schlechten Bedingungen, wann
Adhoc noch geht und gar nicht so schlecht,
obwohl Master/Client zu so einem Augenblick überhaupt nicht für manche
Partner geht.
Nur bei sehr guten Bedingungen zeigt sich Master/Client gegenüber dem
Adhoc/Adhoc vorteilhaft, wie etwa gerade jetzt.
Das ist nicht nachvollziehbar. Von welchen Stationen sprichst Du
konkret, in welchem Zeitraum, ...
Um zu debuggen, sind ein paar konkretere Informationen erforderlich -
hast Du tatsächlich Zugriff auf 6-8 Adhoc-Partner des Brenner NW?
Dass beide Modi zusammen nicht das Optimum sind, sondern eher ein
Workaround, weißt Du ja.
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.
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
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 (!)
und der gesammte brenner Traffic lief bei nur 5-10 MBit/s über mich,
entweder direkt über mein Tunnel oder über ley23 seins.
Dann solltest Du parallel dazu vielleicht am Debugging an Deiner
Verbindung zu io arbeiten?
ich fahre beide Modi gleichzeitig (xbrenner(C).ley21)
so betrifft mich es nicht unbedingt schmerzhaft
Ist das sinnvoll? Oder reduziert das nicht eher unnötig Airtime für
alle teilnehmenden Stationen?
Ich halte das für kein Setup, das die Redundanz verbessert, sondern
eher für das Gegenteil davon.
sinnwoll ist es meiner Meinung nicht, aber das ist im Prinzip
Master/Client Betrieb genauso wenig
ausser bei dedicated 1 zu 1 peers bei voller Bandbreite, aber da ist
dann auch kein adhoc bzw. multilink im Spiel
Naja, dazu gibt es einen wissenschaftlichen Aufsatz, der Deiner
Behauptung nicht ganz gerecht wird:
http://www.comsys.rwth-aachen.de/fileadmin/papers/2011/2011-wirtz-chants.pdf
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.
Mischbetrieb ist dagegen */auf Dauer/* keine gute Idee - als Workaround
für gewisse Symptome funktioniert er zwar, senkt aber Beobachtungen
zufolge die Gesamtperformance.
hätte ich dagegen kein Adhoc und hätte ich nur Client/Master Antrieb
dann leider doch
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?
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.
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.
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.
Was so bald nicht passieren wird, außer es verschwinden alle
WRTs/Buffalos über Nacht aus dem Netz oder werden mit neuerer Firmware
ausgestattet.
Eine Firmware, die eine Mischung aus Attitude Adjustment
(stable/brcm47xx) und der Freifunk-Firmware wäre, könnte ein Ansatz sein.
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.
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>.
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
als ich von ihm.
In welchem Modus denn?
Wie schaut die CRC-Statistik Deines WLAN-Treibers aus?
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
aus dem Internet.
...
http://xbrennerc.ley21.wien.funkfeuer.at/cgi-bin/luci/freifunk/olsr/neighbors/
http://nordwestm.brenner.wien.funkfeuer.at/cgi-bin/luci/freifunk/olsr/neighbors
LG
Erich
--
Wien mailing list
[email protected]
https://lists.funkfeuer.at/mailman/listinfo/wien
