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

Do Nov 2 21:08:44 CET 2006

On Thu, Nov.02. 12:30 +0100, Sven-Ola Tuecke wrote:
> tatsaechlich. Die Abfrage auf der Statusseite tut nix (RTS=leer, trotzdem 
> gruen). Sowas. RTS bringt uns Entspannung vom "Hidden-Node-Problem" und 
> sollte generell fuer alle Datenpakete mit mehr als 250 Byte aktiv sein.

> <Zitat Horst>Mach' doch mal 'ne Antenne dran, dat hilft eher</Zitat>.

moin,

explizit, nein zu RTS, und es ist kein alleiniges problem mit antennen.

<antennen-polemik>

  ja, klar; lassen wir freifunk zu einer menge aus privaten richtfunk-links
  degenerieren, kostet bloß zwei router + antennen + inst-material,
  _ pro kopf _ , das war es, was wir wollten?   Nack.  :-(

  von hochhaus zu hochhaus mit 20dbi-antennen links zu bauen ist spaß,
  interessant wird es auf der straße und in hinterhöfen mit den leuten.

  dabei könnte man gezwungen sein, auf den megatonnen-link zu seiner
  lieblings-nachbarin zu verzichten, zugunsten eines
  allgemein-funktionierenden freifunks... vorerst.

</antennen-polemik>

...mußte mal von dieser seite am tischtuch ziehen.

das folgende bezieht sich ausschließlich auf nodes mit fff-1.2.5 und
neuer, meistens mit festen ARP-einträgen optimiert;  also,

thema "drahtlos"-einstellungen,

sicher:  im "test-labor",
z.b. einer insel-lage wie der des BLO-geländes am nölder-platz z.b., gehen
hand-optimiert stundenlang 3600 KByte/s von stummel zu stummel - über
fast 150m distanz, flachdach <-> hauswand im 2.stock,
freigelände mit einer pappel-reihe dazwischen.
um die ca. ein dutzend ff-nodes dort herum passiert im umkreis von vielen
hundert metern sonst nichts wlan-artiges...

bloß:   "die welt ist anders",
in der krossener- in f´hain, nähe boxh.-platz gab es probleme,
10 KByte/s zu _jeder_ tageszeit über die straße, von balkon zu balkon zu
bringen, keine 30m, sichtkontakt, stummel zu stummel.  
(und besser gleich erwähnt, modulare fehlersuche ist mir bekannt :-( )

und das lag an rts + frag + bitrate .

die default-config der ff-router sollte vom worst-case ausgehen, nicht
von ideal-bedingungen.  wird nicht verhindern, daß fitte leute nach-
bessern, antennen bauen oder kaufen;
  aber den meisten den einstieg und einen optimalen platz für den router
zu finden, erleichtern, "überhaupt erstmal netz haben" ermöglichen,
und die akzeptanz von freifunk fördern.  tausendmal wichtiger.

als "real-world-maintainer" (boah, tm) von mittlerweile >3 dutzend Freifunk-
nodes in berlin hatte ich reichlich gelegenheit, nach ursachen wackelnder
links zu forschen; was oft auf kurzen blick flott lief, stellte sich bei
der kleinster änderung (neuer laptop in reichweite o.ä.) als problem und
meistens anlaß netter telefon-gespräche heraus.

ergebnis:

ein 2MBit-betrieb mit kleinen packeten und ohne RTS ergibt so 50..300KByte/s,
und die sind besser, wenn immer vorhanden, als ein wackelnder +400KB/s
kram, bei dem die routen dauernd wegbrechen, meiner meinung nach.

olsr ist nicht endlos in der lage, wackelnden wifi-unterbau auszugleichen.

mein vorschlag:

      Antenne (Tx + Rx) fest auf einen Anschluß, A oder B
      b+g-mode,
      basic-rate auf "default - je nach wlan modus"
      frameburst aus (damit können wir später nochmal experientieren)
      bit-raten auf 2Mbit fix (vor allem: fix und nur 1, 2, 5.5, 11MBit !!!)
      DTIM 1,                 (standard)
      beacon auf 100          (standard)
      RTS auf 2346            (d.h. RTS-handshake ausschalten !!!)
      frag auf 384            (!!!)

für die schnell-antworter sage ich schonmal ´tschüß, es geht leider nicht
ohne etwas mehr text,

marco

P.S.

   ...zum "warum":

beim (remote-) monitoring am ND ergibt sich ein mir durchaus vertrautes bild,
das mit nur sporadisch funktionierenden links einhergeht.

hier ein auszug der olsr-Werte, jeweils alle 10 Sek. , zwischen
 uli´s (104.1291.17) und ND (104.129.1.1), Dienstag, am frühen Nachmittag:

uli´s (104.1291.17) läuft mit 2MBit, RTS off, FRAG 386 ,

das ND mit ff-defaults.

Local IP        remote IP       Hyst    LQ      lost    total   NLQ     ETX
104.129.1.17    104.129.1.1     0.00    0.80    20      100     0.23    5.50
104.129.1.17    104.129.1.1     0.00    0.84    16      100     0.25    4.82
104.129.1.17    104.129.1.1     0.00    0.75    25      100     0.00    0.00
104.129.1.17    104.129.1.1     0.00    0.74    26      100     0.00    0.00
104.129.1.17    104.129.1.1     0.00    0.74    26      100     0.31    4.36
104.129.1.17    104.129.1.1     0.00    0.81    19      100     0.29    4.31
104.129.1.17    104.129.1.1     0.00    0.81    19      100     0.33    3.75
104.129.1.17    104.129.1.1     0.00    0.81    19      100     0.32    3.89

und dasselbe, nachts gegen 00:00 Uhr:

Local IP        remote IP       Hyst    LQ      lost    total   NLQ     ETX
104.129.1.17    104.129.1.1     0.00    0.75    25      100     0.85    1.57
104.129.1.17    104.129.1.1     0.00    0.74    26      100     0.88    1.54
104.129.1.17    104.129.1.1     0.00    0.71    29      100     0.88    1.60
104.129.1.17    104.129.1.1     0.00    0.65    35      100     0.87    1.78
104.129.1.17    104.129.1.1     0.00    0.69    31      100     0.87    1.67
104.129.1.17    104.129.1.1     0.00    0.65    35      100     0.84    1.83

uli´s .1.17 sieht das ND prächtig, und umgekehrt viel packet-loss (NLQ) bis hin
zum aussetzen;  nachts, wenn nicht mehr viel los ist, zeigt sich, daß die
HF-ebene völlig o.k. läuft, sonst gäbs´ keine ETX stundenlang unter 2.

völlig unzureichend ist, daß der ETX-Wert manchmal sogar bis über 20 ansteigt.
olsr sagt hier ganz einfach, wie´s wirklich läuft - manchmal o.k., bei viel
traffic von günstiger gelegenen (oder lauter schreienden) nodes meistens doch
extra-beschissen für alle anderen.

momente, wo ETX ca. eine halbe Minute auf "0.00" springt, sind ausschließlich
seitens des ND-routers (mit NLQ==0.00) beobachtet worden.  auch zu zeiten
mit "nur" 250 nodes in der routing-table.
dasselbe gibt´s anderorts aber auch mit 10 nodes in insel-lage, bei default-
config.

[@Sven-Ola: daran hat sich auch heute, nach Deinem update gestern nichts getan,
 aber die routing-loop zwingli-ND ist nicht mehr aufgefallen]

  der hohe "normale" packet-loss am ND bei tag ist vor allem dadurch bedingt,
daß sich die nachbarn nicht direkt "sehen", also auch senden, 
wenn ein anderer grade dabei ist, ergo kollisionen am ND, neu-probieren usw.  
(auch als hidden-node problem in der theorie benannt)

 und ja,

dagegen möchte die ff-default-konfig mit dem RTS-handshake für geregeltes
nacheinander und fairness sorgen.

 und nein,

damit das funktioniert, müssten sich alle FF-router _und_ auch
alle nachbar-wifi-netze um und auf kanal 10 an RTS-handshake halten.

  letzteres kann man getrost vergessen, weil wlan-AP´s out-of-the-box mit
abgeschaltetem RTS geliefert werden, und sich kaum ein 0815-DSL-over-wifi
nutzer auch nur traut, mehr als ESSID und passwort bei seinem AP zu
ändern...  und bei vielen laptop treibern ist diese option garnicht
oder nur in den tiefen der menüs oder registry enthalten, ebenso worst-case,
alle außer Freifunk senden einfach (was im grunde garnicht so dumm ist,
weil weniger verwaltung in der luft ;-) !!!

[die geschichte mit gleichberechtigter parallelität von DCF und PCF in
 realen implementierungen glaube ich nicht mehr, papier ist geduldig,
 wie auch roofnet beweist]

aber mal alles schritt für schritt, theorie hin - praxis her:

"RTS-handshake ist nett gemeint (1.Teil)":

(1)
  es reicht nur ein non-RTS wlan-netz in der Umgebung auf kanal 10, um RTS-
  nutzende FF-router fast komplett zum schweigen zu bringen, sobald non-RTS
  traffic läuft.  eine symmetrische aufteilung der "luft-bandbreite" findet
  so schon nicht mehr statt, zu lasten der FF-links!

(1a)
  dazu kommt, daß auf g-only eingestellte - bzw. sich auf g-mode automatisch
  umstellende FF-router offenbar (und eigentlich logischer weise) auch
  RTS-frames mit g-raten senden, die damit für nodes außerhalb der
  "g-Reichweite" un-hörbar sind.  und für b-only sowieso unverständlich sind.

(1b)
  eine in broadcom-routern vorhandene option namens
  "g-mode-auto-protection"   soll dem dadurch abhelfen, daß zumindest die
  nicht-daten preambeln/frames mit b-mode raten versand werden, um b-only devices
  von der existenz und nutzung des kanals seitens im g-mode funkender nodes zu
  informieren.  dies hängt aber von der wahrnehmung sich in reichweite
    befindlichen b-devices seitens der ff-router ab
  (sonst sprechen die offensichtlich optimierend g-mode-RTS),
  und hier scheint es probleme mit dem b-empfang zu geben, s.a. "4a" unten.
  also wenn es schon an dieser stelle, auf seiten der broadcom-wifi-treiber, ein
  problem gibt, dann im zweifel lieber ohne RTS.

[  es ist mir jedenfalls nicht gelungen, mit *_overide usw. eine besserung
   bei aktiviertem RTS hinzukriegen, ja - auch ohne daß wifi dauernd per
   cron o.ä. dazwischen funkt, weder via NVRAM noch per wl ]

"g-mode only paßt nicht so richtig":

(2a)
  der g-only-mode verspricht besseren durchsatz, allerdings,
  es ist mehr S/N-abstand für den g-mode notwendig, er funktioniert also nur
  auf kürzere distanz oder mit stark bündelnden richt-antennen; durch solche
  antennen begrenzt sich die "nachbarschaft" eines nodes aber meistens so
  weit, daß der aufwand an routern und antennen immens ansteigt, um noch von
  einer location in mehrere richtungen kommunizieren zu können.  was das
  grund-konzept der freifunkerei ja eigentlich vorsieht...
    er sollte deshalb vielleicht als "highspeed"-profile in einer späteren
  generation ff-firmware für eng-benachbarte, nicht auf kommunikation mit
  fernen nachbarn angewiesene nodes vorbehalten bleiben
(2b)
  gleichzeitig ist es mit richt-antennen wahrscheinlicher, über größere distanz
  wlan-aktivität anderer wlan-netze auf demselben kanal einzufangen;
  die notwendigkeit, sich "im-band" zu arrangieren, auch mit b-only-netzen,
  bleibt bestehen - oder verschärft sich ggfs. sogar;
  ausnahme-links mit richt-antennen laufen allenfalls bei extremer höhe der
  antennen-standorte (so jenseits des 9. stocks auf beiden seiten) oder
  sonst einfach freiem zwischenfeld richtig rund.
(2c)
  bleibt die nach wie vor die große zahl b-only devices in laptops u.ä.,
  die durch g-only arbeitende ff-router einfach außen vor,
  ausgegrenzt blieben (will man das? klar, alle haben a/b/g atheros-Karten,
  cardbus statt pcmcia; ich schon - keine sorge)

"RTS-handshake ist nett gemeint (2.Teil), lieber kleine fragmentierung":

(3a)
  b-only wifi-netze in der nachbarschaft verstehen diese g-mode RTS-frames
  ebensowenig, wie sie mit g-only laufendem traffic als wlan-aktivität was
  anfangen können.  sie stufen ihn als indifferenzierbare störung ein, und
  versuchen irgendwie dagegen an zu funken, um ihre b-verbindung aufrecht zu
  erhalten.  zusammen mit "3b" ergibt sich der worst-case...
  bis hier die erwähnte wahrnehmung und (ggfs. immer wieder-) einsetzende
  "g-mode-auto-protection" der ff-router passiert, können die wenig bis keinen
  traffic abliefern.  was hier im wifi-treiber passiert ist in-transparent und
  führt jedenfalls zu dauerndem hakeln, ist also unbrauchbar.
(3b)
  da managed-wlan´s out-of-the-box mit maximal-großen fragmenten (2346, also
  ohne fragmentierung) arbeiten, verursachen sie auch die größt-mögliche
  störung, sobald sie der meinung sind, senden zu wollen.
  hier hilft, mit kleinen fragmenten - ohne RTS-handshake - immer wieder zu
  probieren, was wegen kurzer packete mit größerer wahrscheinlichkeit zum
  erfolg führt (sprich, funktioniert ;-)
(3c)
  kleine wlan-packete bedeuten bei kollision weniger verlust an bandbreite
  und ein schnelleres zum zuge kommen aller nodes, treiben ergo höhere IP-
  protokoll-schichten nicht so schnell in timeouts, falls wiederholung
  notwendig wird;  unter ideal-bedingungen kostet die verringerung der
  frag von 2346 runter auf 384 grade mal ca. 15% bandbreite bei 2MBit;
  sonst kosten die wiederholungen langer fragmente ein mehrfaches
  an luft-bandbreite.  da wir nicht ohne kollisionen funken können, lieber
  den mehraufwand pro kollision begrenzen.

"warum feste bitrate einstellen":

(4a)
  auf automatische raten-anpassung eingestellte ff-router neigen zu "insel-
  bildung" mit in kürzerer distanz funkenden nachbarn;  selbst im mixed-
  b+g-mode laufende nodes verlieren dann zeitweilig jegliche olsr-broadcasts
  entfernter nodes, (auch) wenn die fest (oder via auto-rate zurückgefallen)
  im b-mode funken.
  hier scheint ein bug, eine nur exklusiv b- oder g-mode alternativ
  verarbeitende empfangs-kette aus hardware+wlan-treiber, oder ein vom
  hersteller gewolltes/toleriertes(?) "feature"   das fehlverhalten,
  im automatik-rate modus zeitweilig keine b-mode frames zu empfangen,
  auszulösen.
(4b)
  soll ein router als fern-link arbeiten, verhindert auch eine richt-antenne
  "4a" nicht.  im nah-feld der richt-antenne sitzende nachbarn funken
  "direkt in den feed" der richt-antenne, lösen also das problem aus.
(4c)
  solange keine "rück-kopplung" vom routing-protokoll zum wifi-treiber
  für eine topologisch sinnvolle steuerung der bitrate(n) sorgt, kriegen
  wir mit konstanter rate stabilere LQX, stabilere links.

"unter der wifi gürtel-linie":

(6a)
  eine contention-window genannte mechanik soll bei kollision für gerechte
  aufteilung der "luft-bandbreite" unter wlan-nodes sorgen, auch zwischen
  unterschiedlichen logischen netzen (anderer ESSID).   bei belegung
  der frequenz oder kollision wartet ein wlan-device eine sich jedesmal
  verdoppelnde zeitspanne, bevor es einen erneuten sendeversuch unternimmt.
  minimum und maximum der warte-zeitspanne ist in 802.11 standardisiert.
(6b)
  "eigentlich standardisiert",
  leider sieht es so aus, als ob sich nicht alle hersteller/betreiber an
  minimum und maximum halten, um mit ihrem equipment "mehr vom kuchen"
  abzukriegen; sich durch verkürzen von "cwmax" schlagartig wieder in
  funktion setzbare Freifunk-links (ohne RTS und kleiner FRAG) legen diese
  vermutung nahe :-(
(6c)
  durch abspecken ging der zugriff auf diese parameter im laufenden
  betrieb nach der FF-firmware version 1.2.5 komplettt verloren
  (total reduziertes wl - command)

Der Punkt "4a" kann dafür verantwortlich sein, daß es olsr-aussetzer mit ein-
seitiger LQ == 0.0 gibt.  sie verschwinden komplett, sobald die wifi-raten fest
auf b-raten eingestellt sind, also auf 1, 2, 5.5 oder 11Mbit.

fertig.

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