[Discuss] Die Sache mit der Uebertragungsrate (und warum Auto nichtboese ist)
Sven-Ola Tuecke
(spam-protected)
Di Feb 19 09:09:46 CET 2008
Ein Moin nach Wien,
hab' Dank fuer die Zusammenfassung. Genau das war meine Arbeitshypothese bei
der Auswahl der Defaults fuer die Freifunkfirmware. Zwei weitere Punkte:
* Aus praktischen Tests ergibt sich fuer den B-Mode (z.B. 5.5 Mbit) eine
hoehere Reichweite als fuer den G-Mode (z.B. 6 Mbit). Es ist daher sinnvoll,
eine der B-Mode-Rate als Broad/Multicastrate einzustellen. Der Treiber
selbst stellt eigentlich immer 1 Mbit ein, d.h. "Auto Mcast" und "1 Mbit
Mcast" sind defakto dieselben Einstellungen. Es gibt auch keine Treiberlogik
mit "Ich hoere alle anderen Nodes so gut, dass ich mit wenigstens 11 Mbit
Broadcasten kann".
* Die inneren Zustands-Variablen fuer Nachbarn im WLAN-Treiber haben eine
feste Groesze. Bin nicht sicher, aber irgendwo bei 8 oder 12 ist Schluss.
Ein Node mit z.B. 24 Nachbarn in guter Reichweite waehlt daher oft nicht die
optimale Senderate fuer den jeweiligen Nachbarn. Hier kann eine feste
Unicast-Rate sinnvoll sein (typischer "Convention-Fall").
* Im letztgenannten "Alle sitzen auf demselben Platz und wundern sich"-Fall
gibts auszerdem regelmaeszig Aerger mit Probe-Request/Probe-Request-Answer.
Wie die Beacons werden PR-Answers die mit 1 Mbit gesendet. Das tut der
Wlan-Chip automatisch (er hat einen Speicherbereich, in dem die Answers
vorformuliert abgelegt sind). Irgendwas sendet ein Probe-Req Paket und
*alle* Ad-Hoc-Nodes antworten sofort. 50 Gadgets auf der Access-Point-Suche
multipliziert mit 50 Nodes die antworten == Kanal ist zu (Funkzeit komplett
verschwendet). Dafuer gibts einen Hack: "nvram set ff_noprobe=1" ->
cron.minutely -> "/sbin/wifi wdog" -> Nullen in besagtes Muster-Register des
WLAN-Chips. Ich muss daraus mal eine Option auf Admin/Drahtlos machen...
// Sven-Ola
----- Original Message -----
From: "Harald Geyer" <(spam-protected)>
To: <(spam-protected)>
Sent: Monday, February 18, 2008 4:00 AM
Subject: [Discuss] Die Sache mit der Uebertragungsrate (und warum Auto
nichtboese ist)
> Hallo!
>
> Folgendes Mail ist durch eine Diskussion am Samstag auf der
> Convention angeregt worden, als es um verschiedene Metriken
> für Verbindungsqualität ging. Es wurde die Frage aufgeworfen,
> ob es sinnvoll ist Multicastrate und Übertragungsrate
> unterschiedlich einzustellen. Das kann ich nun beantworten.
>
> In der Freifunkfirmware lassen sich zwei Arten von WLAN-Rate einstellen,
> die Multicastrate, die für OLSR-Pakete verwendet wird, und die
> Übertragungsrate, die für unicast frames (also die ganzen
> Nutzdaten) verwendet wird, einstellen.
>
> Beides kann entweder auf einen festen Wert gesetzt werden, oder
> auf "Automatisch" - dann wählt der WLAN-Treiber selbst den Wert,
> den er gerade für sinnvoll hält. Leider gibt es im wiener Netz
> inzwischen soviel OLSR-Traffic, dass eine niedrige Multicastrate
> kontraproduktiv wäre, weil keine Sendezeit für Nutzdaten übrigbleiben
> würde. Deshalb ist es wichtig, dass die Multicastrate auf einen
> festen Wert eingestellt wird. Bei uns haben sich 5.5 Mbps eingebürgert.
>
> Deshalb werden (auf einem gut konfigurierten Device) alle ETX-Werte
> unter der Annahme berechnet, dass die Daten mit 5.5 Mbps versendet
> würden - egal was für die Übertragungsrate tatsächlich eingestellt
> ist. Es wurde die Frage gestellt, ob es dann nicht sinnvoll wäre,
> die Übertragungsrate auch auf 5.5 Mbps zu setzen, damit die reale
> Situation möglichst gut dem Bild des olsrd entspricht.
>
> Die Antwort hängt natürlich stark davon ab, wie der Treiber die
> Übertragungsrate konkret auswählt. Manche Leute wollten nicht recht
> glauben, dass der WLAN-Treiber für jede Ziel-MAC-Adresse mit einer
> eigenen Übertragungsrate sendet. Ich hab' das jetzt noch einmal
> ausprobiert, indem ich von einem Buffalo (193.238.158.178) ausgehend
> ein nahes Device (78.41.112.199) und ein etwas weiter entferntes
> Device (193.238.156.7) - beides 1-Hop Nachbarn - gleichzeitig
> gepingt und die Pakete mit horst mitgesniffed habe. Das Folgende
> sind Auszüge aus dem Log zu drei verschiedenen Zeiten. In der
> zweiten Spalte steht die Rate mit der das Paket übertragen wurde:
>
>
> -86/-95 18 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -87/-95 18 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -86/-95 18 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -77/-95 5 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -79/-95 5 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -86/-95 18 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -79/-95 5 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -75/-95 5 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -87/-95 18 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -79/-95 5 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -86/-95 18 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -86/-95 18 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
>
>
> -77/-95 5 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -77/-95 5 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -77/-95 5 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -84/-95 24 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -77/-95 5 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -86/-95 24 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -86/-95 24 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -79/-95 5 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -88/-95 24 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -79/-95 5 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -79/-95 5 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.157.16
> -87/-95 24 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
>
>
> -86/-95 24 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -73/-95 11 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -83/-95 24 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -82/-95 24 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -75/-95 11 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -83/-95 24 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -83/-95 24 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -83/-95 24 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -75/-95 11 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -86/-95 24 00:16:01:92:8b:f3 PING 193.238.158.178 -> 78.41.112.199
> -77/-95 11 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
> -75/-95 11 00:16:01:92:8b:f3 PING 193.238.158.178 -> 193.238.156.7
>
>
> Geht man davon aus, dass der WLAN-Treiber für die Wahl der
> Übertragungsrate eine halbwegs gute Heuristik hat, die auf hohen
> Datendurchsatz abzielt, dann ist es besser, ihn selbst wählen zu
> lassen als einen fixen Wert vorzugeben. Selbst wenn die ETX-Metrik
> für die reale Situation nicht die ideale Route auswählt, ist es
> immer noch besser auf der nicht-idealen Route mehr Bandbreite zu
> haben als weniger.
>
> Von da her scheint mir folgende Konfiguration für den Normalfall am
> besten:
> Multicastrate: fester Wert, mindestens 5.5 Mbps
> Übertragungsrate: automatisch
>
> Ob man die schnell ändernde Übertragungsrate jemals sinnvoll für
> eine ETT-Metrik (vielleicht sollte man statt Metrik eher Kostenfunktion
> sagen) verwenden können wird, ist ein anderes Problem.
>
>
--------------------------------------------------------------------------------
--
Discuss mailing list
(spam-protected)
http://lists.funkfeuer.at/mailman/listinfo/discuss
Mehr Informationen über die Mailingliste Discuss