[Discuss] Die Sache mit der Uebertragungsrate (und warum Auto nicht boese ist)

[Markus Kittenberger]

On 2/18/08, Harald Geyer <(spam-protected)> wrote:

> 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.


Super, nun ist mal klar dass verschiedene rates im auto mode verwendet
werden,..
und der olsrd mit fixer mrate keine links produziert die bei unicast-auto
dann gar nicht klappen können,..
und ebenso ist klar warum lahme links ihr nachbarn der auto rate hat, nicht
(komplett) unbrauchbar machen können

aber: fixe unicast die weitaus höher als die multicastrate liegt: ist BÖSE!!

Gut wär noch ein Testsetup auf maximalen durchsatz abzielt,.. (also nicht
nur pingen)
Und dabei auszutesten wieviel airtime (und im endeffekt bandbreite) ein oder
mehr lahme links näm schnelleren 'Link abgraben können,..

dazu passend hab ich unlägst praxiserfahrungen gemacht:
der link heuberg zur mirv13, erreicht nur mit manuell gesetzter
unicastrate (18mbit) 7-9Mbit netto,..
mit auto rate sinds meist bestenfalls 4 mbit netto

ich vermute die höhere netto bandbreite ergibt sich hier wohl (teilweise)
dadurch dass es den "schlechtergestellten" nachbarn der mirv13 durch die für
sie deutlich zu hohe rate wohl komplett verunmöglicht wird noch was zu
empfangen,..

allerdings sollte ich da dann besser auch die multicast rate hochdrehen, ...
(weil dann verschwinden die "boykotierten" links auch gleich im olsr)

noch weiter "verkomplizierend" kommt dann ja noch hinzu, dass die bandbreite
auf einem link je nach richtung unterschiedlich ist, der sender definiert
diese,..

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


dies bezweifle ich ,.. (-;
ich denke der heuristik ist wohl auch sehr wichtig, jedem nachbarn der noch
reale chancen hat ein paar bytes zu empfangen diese zu schicken
aber austesten bringt da sicher konkretere erkenntnisse (als nur mein obiger
erfahrungsbericht)

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.


wirklich profitieren eigentlich nur die schlechten links, hängt also
von der konstellation und von gerade anfallenden traffic ab, was nun
besser ist,..
denn guten links wird wohl massiv airtime "gestohlen" (allerdings können sie
ihre velbreibende airtime besser nutzen)

Von da her scheint mir folgende Konfiguration für den Normalfall am
> besten:
> Multicastrate: fester Wert, mindestens 5.5 Mbps
> Übertragungsrate: automatisch


noch idealer wäre evt., multicast 5,5, unicast 5,5 mbit oder höher (-;
d.h. auto ist gut, aber es einschränken zu können, wäre fein, (manche
devices haben derartiges in der firmware drinnen (z.B.: osbridges))

evt. geht das bei den atheros/broadcom tereiben ja auch??

aber je nachdem ob die nachbarn alternativen haben oder nicht, usw. siehts
individuell immer anders aus,..
ich würd mich keineswegs trauen eine allgemeine empfehlung abzugeben,..

nur die gern eingetragenen hohen unicastraten find ich BEDENKLICH!!!
bzw. die dort NIEDRIGEREN multicastraten,..

nur wenn man multicast hochdreht, bekommtd er auf durchsatz tuned link dann
nen schlechten ETX , und diesen per lqmult wieder gutzustellen
ist tricky, (bzw. verursacht wieder noch mehr unbrauchbare metrikwerte)
man kommt mit ETX da einfach nicht sinnvoll weiter,..

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.


der empfänger kennt ja (theoretisch) seine aktuelle empfangsrate, und seinen
aktuellen loss,.. rechnet somit seinen aktuelle bandbreite aus
d.h. nicht die statistik über rate und loss machen, und dann damit rechnen,
sondern über die errechneten(/gemessene) netto-bandbreitenwerte

seh da eigentlich kein so grosses "theoretisches" problem,..

zumindest nicht wenn man nur besser als ETX als Ziel annimt,..

lg Markus
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/discuss/attachments/20080219/50878371/attachment.htm>