<br><br><div><span class="gmail_quote">On 2/18/08, <b class="gmail_sendername">Harald Geyer</b> <<a href="mailto:harald@lefant.net">harald@lefant.net</a>> wrote:</span><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
Die Antwort hängt natürlich stark davon ab, wie der Treiber die<br>Übertragungsrate konkret auswählt. Manche Leute wollten nicht recht<br>glauben, dass der WLAN-Treiber für jede Ziel-MAC-Adresse mit einer<br>eigenen Übertragungsrate sendet. Ich hab' das jetzt noch einmal<br>
ausprobiert, indem ich von einem Buffalo (<a href="http://193.238.158.178">193.238.158.178</a>) ausgehend<br>ein nahes Device (<a href="http://78.41.112.199">78.41.112.199</a>) und ein etwas weiter entferntes<br>Device (<a href="http://193.238.156.7">193.238.156.7</a>) - beides 1-Hop Nachbarn - gleichzeitig<br>
gepingt und die Pakete mit horst mitgesniffed habe.</blockquote><div><br>Super, nun ist mal klar dass verschiedene rates im auto mode verwendet werden,..<br>und der olsrd mit fixer mrate keine links produziert die bei unicast-auto dann gar nicht klappen können,..<br>
und ebenso ist klar warum lahme links ihr nachbarn der auto rate hat, nicht (komplett) unbrauchbar machen können<br><br>aber: fixe unicast die weitaus höher als die multicastrate liegt: ist BÖSE!!<br> <br>Gut wär noch ein Testsetup auf maximalen durchsatz abzielt,.. (also nicht nur pingen)<br>
Und dabei auszutesten wieviel airtime (und im endeffekt bandbreite) ein oder mehr lahme links näm schnelleren 'Link abgraben können,..<br><br>dazu passend hab ich unlägst praxiserfahrungen gemacht:<br>der link heuberg zur mirv13, erreicht nur mit manuell gesetzter unicastrate (18mbit) 7-9Mbit netto,..<br>
mit auto rate sinds meist bestenfalls 4 mbit netto<br><br>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,..<br>
<br>allerdings sollte ich da dann besser auch die multicast rate hochdrehen, ... (weil dann verschwinden die "boykotierten" links auch gleich im olsr)<br><br>noch weiter "verkomplizierend" kommt dann ja noch hinzu, dass die bandbreite auf einem link je nach richtung unterschiedlich ist, der sender definiert diese,..<br>
<br></div><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
Geht man davon aus, dass der WLAN-Treiber für die Wahl der<br>Übertragungsrate eine halbwegs gute Heuristik hat, die auf hohen<br>Datendurchsatz abzielt, dann ist es besser, ihn selbst wählen zu</blockquote><div><br>dies bezweifle ich ,.. (-;<br>
ich denke der heuristik ist wohl auch sehr wichtig, jedem nachbarn der noch reale chancen hat ein paar bytes zu empfangen diese zu schicken<br>aber austesten bringt da sicher konkretere erkenntnisse (als nur mein obiger erfahrungsbericht)<br>
</div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
lassen als einen fixen Wert vorzugeben. Selbst wenn die ETX-Metrik<br>für die reale Situation nicht die ideale Route auswählt, ist es<br>immer noch besser auf der nicht-idealen Route mehr Bandbreite zu<br>haben als weniger.</blockquote>
<div><br>wirklich profitieren eigentlich nur die schlechten links, hängt also von der konstellation und von gerade anfallenden traffic ab, was nun besser ist,.. <br>denn guten links wird wohl massiv airtime "gestohlen" (allerdings können sie ihre velbreibende airtime besser nutzen)<br>
</div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
Von da her scheint mir folgende Konfiguration für den Normalfall am<br>besten:<br>Multicastrate: fester Wert, mindestens 5.5 Mbps<br>Übertragungsrate: automatisch</blockquote><div><br>noch idealer wäre evt., multicast 5,5, unicast 5,5 mbit oder höher (-;<br>
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))<br><br>evt. geht das bei den atheros/broadcom tereiben ja auch??<br><br>aber je nachdem ob die nachbarn alternativen haben oder nicht, usw. siehts individuell immer anders aus,..<br>
ich würd mich keineswegs trauen eine allgemeine empfehlung abzugeben,..<br><br>nur die gern eingetragenen hohen unicastraten find ich BEDENKLICH!!!<br>bzw. die dort NIEDRIGEREN multicastraten,..<br><br>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) <br>
man kommt mit ETX da einfach nicht sinnvoll weiter,..<br></div><br><blockquote class="gmail_quote" style="margin-top: 0; margin-right: 0; margin-bottom: 0; margin-left: 0; margin-left: 0.80ex; border-left-color: #cccccc; border-left-width: 1px; border-left-style: solid; padding-left: 1ex">
Ob man die schnell ändernde Übertragungsrate jemals sinnvoll für<br>eine ETT-Metrik (vielleicht sollte man statt Metrik eher Kostenfunktion<br>sagen) verwenden können wird, ist ein anderes Problem.</blockquote><div><br>der empfänger kennt ja (theoretisch) seine aktuelle empfangsrate, und seinen aktuellen loss,.. rechnet somit seinen aktuelle bandbreite aus<br>
d.h. nicht die statistik über rate und loss machen, und dann damit rechnen, sondern über die errechneten(/gemessene) netto-bandbreitenwerte<br> <br></div></div>seh da eigentlich kein so grosses "theoretisches" problem,..<br>
<br>zumindest nicht wenn man nur besser als ETX als Ziel annimt,..<br><br>lg Markus<br>