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

Harald Geyer (spam-protected)
Sa Feb 23 17:00:13 CET 2008


Hi Markus!

Markus Kittenberger" <(spam-protected)>: 
 
> aber: fixe unicast die weitaus höher als die multicastrate liegt: ist 
> BÖSE!!

ACK

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

Da der WLAN-Treiber wohl kein traffic shaping macht, vermute ich einmal,
dass jeder Link die selbe Chance hat Pakete zu schichken. Also vermutlich
kann ein schlechter Link viel airtime verbraten.

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

Da bin ich eher skeptisch. Über mirv13 gehen zwar ein paar default
routen, aber die werden nicht ständig traffic haben... Umgekehrt, wenn
die Nachbarn nichts mehr empfangen, aber die Route noch da ist, dann
versucht mirv13 die Pakete bis zu irgendeinem Timeout immer wieder zu
senden, was ebenfalls airtime verbrät!

Ich vermute eher, dass du mit händischem herumprobieren einfach eine
bessere Rate gewählt hast als die Heuristik des Treibers. Das ist zumindest
für kurze Zeit, wo sich das Funkwetter nicht ändert, bestimmt leicht
möglich - es ist ja nur eine Heuristik.
Nachteil ist halt, dass du damit immer nur einen bestimmten Link
optimieren kannst und alle anderen möglicherweise verschlechterst...

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

Unbedingt! siehe oben.

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

Ja, das ist der Punkt, wo eine Fest Übertragungsrate IMHO am ehesten
Sinn macht: Bei der Wahl der Senderate scheint der S/N-Ratio der
empfangenen frames eine wichtige Rolle zu spielen. Angenommen
A ist exponiert und hat viel noise während B an einer geschützten
Stelle steht, wo fast nur A empfangen wird.

A könnte mit hohe Rate senden, tut es aber nicht, weil er die frames
von B schlecht empfängt. In so einem Fall könnte man mit einer festen
Einstellung viel gewinnen. Sieht man aber meist eh an LQ-NLQ ob die
links symmetrisch sind oder nicht.

> 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

Ich meinte: hohen Datendurchsatz für jeden Link separat betrachtet.
(Also ein paar Byte sind mehr als nix.) Einzelne Links bevorzugen kann
man vermutlich nur mit traffic shaping, wie wir's ja schon für die OLSR
Pakete haben. Freiwillige?

> 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,..
> den guten links wird wohl massiv airtime "gestohlen" (allerdings können 
> sie
> ihre velbreibende airtime besser nutzen)

Naja, die schlechten Links sollte der olsrd ja nicht für eine Route
auswählen ...

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

> es empfielt sich:
> ipkg install wl-adv
> 
> wl ratedump
> gibt die aktuellen senderaten per nachbar mac aus (klappt bei mir nicht)

Bei mir auch nicht. Selbst "wl ratedump <mac>" tut nichts.

> mit wl suprates kann man das rateset überschreiben (und wohl die für auto
> möglichen werte einschränken)
> (nur 811.g) (evt. betrifft das dann auch beacon und co (die sonst ja auf 1
> mbit sind))

Ich hab's ausprobiert:
suprates hat sich zwar mein setting gemerkt und mir wieder ausgegeben,
aber Einfluss auf die gewählten Senderaten hatte das leider
keinen - egal ob nur g-mode oder nicht. Ich will nicht ausschließen,
dass es nicht doch eine folge von Befehlen gibt, mit der es geht
(Treiber neu initialisieren oder was weiß ich) aber ich hab's bisher
jedenfalls nicht zusammengebracht...

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

Full ACK. Das macht überhaupt keinen Sinn.
 
> nur wenn man multicast hochdreht, bekommt der 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,..

Ich vermute einmal, wenn der ETX deutlich schlechter wird, dann ist
die Rate eh schon zu hoch (für optimalen Durchsatz), weil sobald 
es merklichen frame loss gibt, müssen ACK timeouts abgewartet werden,
was wahrscheinlich auch nicht gut ist...

Liebe Grüße,
Harald




Mehr Informationen über die Mailingliste Discuss