[Wien] nordwestM.brenner schlechter als nordwest.brenner

Fr Dez 6 13:16:14 CET 2013

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
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/wien/attachments/20131206/ccdca178/attachment.htm>
-------------- nächster Teil --------------
--
Wien mailing list
(spam-protected)
https://lists.funkfeuer.at/mailman/listinfo/wien