[Berlin-wireless] Stoepsel Freifunk Ossastraße

Sa Mär 15 09:12:28 CET 2014

Moin Stoepsel, et.al,

mittlerweile ist der Link ja ganz OK. Allerdings trotzdem nicht optimal.
Ich habe den starken Verdacht, dass wir uns gegenseitig "totschreien".
Mithin die Empfangsprobleme hausgemacht sind. Da wird auch keine dolle
Funkmesskiste von R+S helfen fürchte ich. Sondern nur ein bisserl
Nachdenken. Ich schreib' mal ein paar Stichpunkte auf:

- Die Emmaus (und die Zwingli) sind bei Kanal 13 / 2.4 Ghz relativ taub.
Das sieht man an den asymmetrischen ETX-Werten. Ich bemerke es z.B. auch
selbst, weil ich seit Jahren an Bockis Kiste in Richtung Süden hänge:
die 104.130.77.80 ist auf dem Hochhaus gegenüber MTV am Osthafen und
guckt auf meinen Balkon. In Empfangsrichtung zu mir alles wie gewohnt -
ich wohn' ja sozusagen im Windschatten - aber die Senderichtung (zu
Bocki) ist deutlich mieser geworden.

- Ich hatte Anha in der Leitung (der wohnt in Köpenick irgendwo am
Müggelsee). Der beschwerte sich, das "die Emmaus und die Zwingli seh'
ich recht gut, aber ich kann nix senden". Das sind 14 Kilometer. Und er
hatte wohl wie gewohnt auf 2.4 Ghz mit einem WRT-mit-Uralt-Firmware
probiert. 14 Kilometer ist die halbe Stadt. So viel Sendereichweite auf
2.4 ist unnütz. Er hat mittlerweile eine 5 Ghz-NanoStation in Betrieb
und das geht um Klassen besser, auch wenn da noch Optimierungspotential
vorhanden ist.

-  Ich hab' dann auf der Zwingli und der Emmaus die MCast-Rate deutlich
nach oben geschraubt. Zur Erläuterung: die Chips / Treiber verwalten
eine variable Datenrate für Unicast (Basic-Rateset). Die wird je nach
Radiosituation hoch- und 'runtergeregelt. Unicast ist dann, wenn die
MAC-Adresse des Kommunikationspartners bekannt ist und ein Datenpaket
mit einer Ziel-MAC-Adresse ungleich FF:FF:FF:FF:FF:FF gesendet werden
soll. Das sind Datenpakete (Normaldaten, 802.11n-QDaten,
ACK-Antwortpakete und Probe-Answers). Und dann gibt es da noch die
Multicast-Rate. Die kommt zur Anwendung, wenn ein Rundrufpaket gesendet
werden soll. Also mit Ziel-MAC-Adresse FF:FF:FF:FF:FF:FF ohne
ACK-Antwort. Das sind ARP-Whohas?, IPv6-NDP, OLSR-Pakete,
Batman-ADV-OGMs, Beacons, Proberequests, RTS, CTS usw. Die
Multicast-Rate ist fest eingestellt. Und häufig erstmal auf den
niedrigsten Wert: 1 MBit bei 802.11b/g. Und wir senden ja jetzt nicht
nur OLSR-Rundrufe sondern das Batman-ADV erzeugt ja auch noch welche.
Quantitative Untersuchung hab' ich jetzt aber noch nicht gemacht.

- Das Senden eines (längeren) 1 MBit-Paket dauert ewig. Und belegt in
der Zeit die Luft. Ich hatte damals aus dem Grund in der Uralt-Firmware
mal die Multicast-Datenrate auf 5.5 MBit voreingestellt. 5.5 ist B-Mode.
5.5 und 11 MBit im B-Mode waren zumindest mit den alten WRTs wesentlich
zuverlässiger / weiterreichend als z.B. 6 MBit im G-Mode. Das ist alle
Jahre her, aber die aktuelle PBerg-Firmware nutzt immer noch diese
5.5-Vorgabe: "uci show wireless|grep rate" zeigt es an. Übrigens konnte
man zwar bei den alten Geräten die Multicast-Rate einstellen, bestimmte
Pakete (Beacons, RTS/CTS, Probeanswer) wurden aber trotzdem mit 1 MBit
gesendet. Aus dem Grund ist es zumindest bei den alten WRTs auch ratsam,
die Beacon-Häufigkeit (10 mal die Sekunde) 'runterzudrehen.

- Und es gab damals einen Software-Schalter für "sende keine
Probe-Answer". Hintergrund ist der, dass in der Stadt / auf einer
Veranstaltung relativ viele Mobiltelefone / Laptops usw. mit aktiven
WLAN unterwegs sind, die alle auf automatisches Verbinden bei
Verfügbarkeit eines bekannten WLANs eingestellt sind. Die tun das mit
"Active Scanning". Senden also Probe-Requests. Und unsere AdHoc-Radios
antworten alle mit Probe-Answer. Wenn 8 AdHoc-Radios in der Nähe sind
also sozusagen 8-mal verstärkt. Alles auf 1 MBit - die Luftzeit wird
dann aber einer gewissen Gerätezahl komplett mit Probes / Answers
verbraucht.

- Kommen wir mal zu aktuellen Geräten / Firmwares / Treibern. Bei den
Ubiquity-M2 mit Ath9k ist die Situation etwas anders. Man kann ebenfalls
eine Multicast-Rate einstellen. Und zwei (soweit mir bekannt ist
voneinander unabhängigen) Sets aus möglichen Unicast-Senderaten:
"legacy-2.4" und "mcs-2.4" (siehe "iw | grep rate"). Legacy meint
"802.11b/g" und MCS meint "802.11g/n". Die Multicast-Rate stellt bei den
Ath9k-Geräten offenbar 802.11b/g für Broadcasts ein, ein Erzwingen von
802.11g/n für Broadcasts geht offenbar nicht. Mit der Multicast-Rate
kann man also nicht "ignoriere alte B- und G- Radios komplett und mach'
nur noch N" einstellen. 

- Jedenfalls beeinflusst die Multicast-Rate bei Ath9k auch die Senderate
für Beacons und Probe-Answers. Das ist anders als früher. Wobei RTS/CTS
immer noch auf 1 MBit gesendet werden, aber die höhere Datenrate bei
Beacons ist ja schonmal ein Fortschritt. Ich hab' dann auf der Emmaus
einfach mal Multicast=36 Mbit eingestellt. Und z.B. nachgeschaut, ob der
Link zur 104.196.0.112 (Stoepsel2 in der Ossastraße) symmetrischer wird.
Tut er auch: LQ (Emma-Empfang) wird um einiges besser und NLQ
(Emma-Senden) wird nicht viel schlechter. Mit der Theorie hab' ich mich
dann mit meinem Mobiltelefon auf den Hügel am Ende des Görlitzer Parks
gestellt, das sind ca. 1 Km und Kirche gut im Blickfeld. Es geht doch
nix über "Ausprobieren" ;-) Jedenfalls musste ich die Multicast-Rate für
den Access-Point-VAP dann wieder 'runterdrehen (auf 6 MBit), damit ich
einigermaßen akzeptable Download-Werte auf meinem Mobiltelefon erhalte
(ca. 300 KByte/sek).

Die nächsten Schritte wären: Einstellen und ausprobieren, ob die
Unicast-Datenrate wirklich nicht mehr in den B-Mode abfallen kann: 1, 2,
5.5, 11 MBit/s sollten auch unter übelsten Radio-Bedingungen nicht
benutzt werden. B-Mode ist nicht mehr. Am liebsten wäre es mir wir im
A-Mode: die niedrigste Rate ist 6 MBit. Wenn ein Gerät da keine
Verbindung herstellt: Pech. Mir fehlt auch der Schalter: "keine Antwort
auf Probe-Answer". Und der Schalter: Weg-mit-der-B-Mode-Protection (das
ist: wenn ein G-Mode-Paket gesendet werden soll, wird für evt.
vorhandene B-Mode-Geräte ein RTS/CTS gesendet "haltet mal die Klappe".
Kostet alles zusätzliche Luftzeit wegen 1 MBit.

Dann wäre da noch die Sendefeldstärke. Die soll noch *runter*. Bis
Nachbarn mit einigermaßen akzeptabler Antenne in etwa zur Emmaus
symmetrische ETX-Werte anzeigen. 36-MBit-Broadcasts ist vielleicht etwas
radikal, ich tendiere eher zu 24-MBit -> sind Erfahrungswerte und nicht
in Stein gemeisselt. Möglich, dass so Kaninchendraht über den
Fenstergittern der Emmaus eine bessere Entkoppelung der 2.4-Nanostations
macht. Offenbar funkt es durch die vorhandenen Gitter mit Maschenweite ~
3cm durch, bin aber nicht ganz sicher denn das ist Nahfeld und da geht
"um die Ecke". Und dann gibt's da immer noch das Konzept, was Bastian
und Elektra derzeit auf der Zwingli fahren: jedes Node-chen sein
Kanäl-chen. Also mehr von dem allgemein vorhandenen Frequenzkuchen zu
benutzen. Aber das wäre für mich jedenfalls erst der letzte
Optimierungsschritt.

Ach und als Tipp: das Horst-Monitoring-Tool funzt auch mit Ath9k,
bequemes Startscript siehe
http://wiki.freifunk.net/Berlin:Standorte:Emmauskirche.

Gruß // Sven-Ola

Am 14.03.2014 10:40, schrieb Christian Heise:
> wobei mir der Link zur Emma immer noch zu schlecht ist. Seit dem
> Upgrade auf der Emma habe ich immer noch sehr üble ETX Werte, obwohl
> ich heute die Antenne neu ausgerichtet habe. Zur Not muss ich mir mal
> den Rode & Schwarz FSH3 von Arbeit mitnehmen und die Pegel prüfen und
> evtl. nochmal genau einmessen. 

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 263 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20140315/11133007/attachment.pgp>