[Berlin-wireless] default-config der ff-router sollte vom worst-case ausgehen - was: Immer wieder MTU

Mi Nov 15 13:34:50 CET 2006

On Mon, Nov.13. 16:38 +0100, Rolf Pfeiffer wrote:
> Am Donnerstag 02 November 2006 21:08 schrieb Marco Tidow:
> > explizit, nein zu RTS, und es ist kein alleiniges problem mit antennen...
> 
> Es ist sehr wohl ein Problem der Antennen. Aber die Problemkinder sind NICHT 
> die Pimmel auf den Schreibtischen, sondern die "flächenabdeckenden" 
> leistungsstarken Rund- und Sektorstrahler.

> Früher - als es nur wenige weitentfernte Knoten gab - waren sie sinvoll und 
> notwendig, um überhaupt Links auf die Beine zu stellen. Heute fallen die uns 
> auf die Füße. Sie fangen nämlich RTS aus der ganzen Welt ein - und antworten 
> brav mit einem CTS - das bis ans andere Ende der Welt zu hören ist.

> Abschaltung des Handshakes heißt: statt kultiviertem Gespräch wildes 
> Durcheinanderbrüllen. Und ja - irgendetwas davon geht auch durch. Aber damit 
> erreicht man bestenfalls ein Stop-and-Go. Anders kann ich die stolz 
> präsentierten 10kB/s nicht bezeichnen.

Hi Rolf, tschuldigung, aber habe nicht den Eindruck als hättest Du mein
posting genau gelesen.

von 10kB/s schrieb ich im Zusammenhang einer früher _OFT_ nicht mal auf diesem
minimal-level funktionierenden verbindung über _30m_, quer über die straße.
dort gehen jetzt z.Z. ca. 400kByte/s ... mit pimmeln, draußen, ohne RTS, 2Mbit
fix und trotz 20 anderen wifi-netzen nebenan, davon mehrere auf kanal 11, eins
managed auf 10...

N.B. "leistungsstarker rundstrahler" ist ein widerspruch in sich;  wenn sie
gewinn machen, dann ist ihre charakteristik eine flache scheibe, so daß nur
andere in derselben ebene was vom signal haben; meistens sind die besenstiele
aber sowieso bloß schrott; daß mensch dann die sendeleistung hochdreht, ist
naheliegend, dachte, die wären schon seit langem ausrangiert - hamburg sucht
grade welche, (nee nix für ungut, hallo alex ;-)

auf die problematik, daß managed-wlan´s, die auf demselben kanal funken, und
_eben_kein_RTS_und_maximale_FRAG_ verwenden, und damit unsere adhoc-links
platt-senden, geht´s Du mit keinem wort ein.  DAS ist aber aber das tot-
tot-kriterium für RTS/CTS überhaupt, abgesehen davon, daß ich mir ein
stadtweites handshaking sowieso nicht plausibel vorstellen kann!

war zunächst auch davon ausgegangen, daß hersteller- und managed/adhoc -mode
unabhängig sich wifi-devices per congestion-avoidance ("wl interference") und
RTS im dem fall, daß mehrere (logisch wg. anderer *SSID getrennte) netze
parallel auf demselben kanal funken, sich die luft "proportional" teilen;

DEM IST NICHT SO.  sich "RTS-höflich" verhaltende ff-router werden einfach
von managed AP´s etc. platt-gesendet.  selbst wenn sich alle an minimales und
maximales congestion-window halten, werden evtl. auch einfach nur die RTS/CTS-
packets überfahren, erst recht durch b-devices, wenn unsere router g-mode
RTS/CTS sprechen...

> Die Festlegung der Bitraten finde ich ganz schlimm. Wir haben in der Regel 
> mehrere Nachbarn, zu denen unterschiedliche Übertragungsraten möglich sind. 
> Außerdem ändern die sich (Laubbewuchs, Regen, ...). Ist die Rate zu niedrig, 
> blockiere ich die Kommunikation für andere unnötig lange. Ist sie zu hoch, 
> geht gar nichts. Und damit unter diesen Bedingungen überhaupt was durchgeht, 
> muß es in klitzekleine Häppchen zerlegt werden.

ja, feste bit-raten zu setzen ist eine miese zwischenlösung, solange es noch 
keine rückkopplung/steuerung der

   bit-raten und

   sendeleistung und

   des kanal-wechsels (o.k. DAS ist wirklich zukunfts-träumerei...)

aus dem routing-proto gibt - aber noch sinnloser ist derzeit, sich auf
eine automatik zu verlassen, die

  1. für SOHO-einsatz mit dicht beieinanderliegenden wifi-devices gebaut wurde

  2. nur eine begrenzte + unbekannte zahl wifi-devices "im blick" behalten,
     sprich radio-/treiber-intern mit individueller bit-rate verwalten kann
     [ wenn hier jemand mehr als nur "ich habe mal gehört", "vermute daß" etc.
       zu bieten hat, raus damit ]

  3. eindeutig das verhalten zeigt, zu hohen bit-raten zu tendieren, wenn
     nahe nachbarn vorhanden sind, und dabei entfernte irgendwann zu überhören,
     bzw. zu leise und mit zu hoher bit-rate, als daß die es noch hören könnten
     und die näher beieinander liegenden zu einer isolierten funk-insel werden
     läßt (was ich Dir gern beispielhaft vorführen kann ;-)

Natürlich macht es sinn, auf kurze entfernung mit hohen raten und nur auf
längeren (als richtfunk-) strecken mit niedrigeren zu arbeiten.  letzteres
widerspricht zwar gradezu dem "backbone"-gedanken, läßt sich wegen der für
performante g-mode links notwendigen 20..24db mehr feldstärke
aber nunmal nicht immer realisieren.
bestes beispiel sind unsere kirch-funktürme mit micker-antennen; selbst wenn
ich mit einer guten richt-antenne draufhalte, reichts oft nicht für mehr
als 2Mbit über mehr als ein paar hundert meter.

aber wenigstens mildert sich damit schonmal die congestion der luft.

derzeit enthält die ff-software mwn noch nicht einmal eine einstell-möglichkeit
für die mrate (und sei es nur, sie beim wifi-init auf dieselbe einstellung
wie die "rate" zu setzen...) von der web-interface ebene aus.

natürlich können ein paar leute wie Du und ich per shell alles machen...

aber eben nicht _ALLE_ und _SELBST_ !!!!!!!!!

DESHALB mein vorschlag, wenigstens beim derzeitigen stand der software,
um stabilere routen zu bekommen.

> Wir investieren inzwischen in 5GHz-Technik. Dann können wir von unseren 
> geliebten Notebook-Usern doch wenigstens die Investition in eine G-Karte 
> erwarten.

das halte ich nicht für gegeneinander aufrechenbar,
ist so einfach nicht meine idee von freifunk  :-(

sorry für´s schreien, gruß, marco

_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin