2011/12/10 Adi Kriegisch <span dir="ltr"><<a href="mailto:adi@kriegisch.at">adi@kriegisch.at</a>></span><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hallo!<br>
<div class="im"><br>
> Da ist auch ein (minimales) tc setup drinnen... damals hat's nichts<br>
> gebracht, weil ein "feature" von madwifi alle tc settings umgangen hat,<br>
><br>
> ich fürchte derartige "features" gibts idr weiterhin,..<br>
> (was eigene queues in tc zu konfigurieren bei wifi interfaces weiterhin<br>
> ... macht)<br>
> da eben die treiber inzwischen interne queues haben, (und sich das wohl<br>
> auch nit mehr aendern wird *G)<br>
</div>Also ich dachte für den Anfang erst mal an etwas wie das hier:<br>
| tc qdisc add dev wifi0 root sfq perturb 10 </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
(für alle Interfaces des Routers wird der FIFO-Algorithmus durch<br>
"Stochastic Fair Queueing" ersetzt).<br>
<br>
Die vorhandenen Queues in den Treibern werden die "neue" Reihenfolge der<br>
Pakete (durch SFQ) imho höchstens minimal verändern.</blockquote><div>potentiell aber auch komplett, <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Der erwünschte Effekt<br>
-- nämlich interaktive oder kurzlebige Verbindungen fairer zu behandeln --<br>
ist so auf jeden Fall mal gegeben.<br></blockquote><div>bei treibern ohne jegliche backpressure, hat ne vorgeschaltete queue übrigens null auswirkung ,.. (da die treiber pakete droppen, und die vorgeschaltete queue immer leer bleibt, also nitmal reordern kann)</div>
<div><br></div><div>ich sag nun mal nicht das neue ath9ks ueberhaupt keine backpressure haben, afair jedoch ältere haben definitv keine, same madwifi (ausser er ist entsprechend gepatched), oder ath5ks,..</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Wenn man das noch in ein schönes Extrapaket packt und mit einer eigenen<br>
Konfiguration versieht, haben wir mal etwas mit dem wir loslegen können.<br>
(Die Firewall muss eh extra gepatched werden, damit da auch korrekte<br>
NOTRACK-Regeln erzeugt werden)<br>
<div class="im"><br>
> dafür sollten (alle?) 802.11 treiber jedoch das skb->priority feld<br>
> honorieren, d.h. darüber ist deren eigene (üblicherweise basierend auf TOS<br>
> bits) packet klassifiziereung (in die treiber-eigenen queues)<br>
> overrule-able,..<br>
</div>Wenn sie das tun, super! </blockquote><div>evt hast mich falsch verstanden, (auch weil du unten für OLSR pakete die TOS bits nicht aendern wolltest, für DNS aber schon,..)<br>ich will (auf nem transit node) keineswegs die TOS bits von irgendwelchen paketen aendern,.. (das widerspräche imho definitv dem pico-peering (und gefällt mir auch sonst nicht,..)) </div>
<div><br></div><div>(ausser evt. wenn alles andere scheitert, könnte man darüber dann doch nachdenken)</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Dann setzen wir passende Flags für DNS in der<br>
Firmware und alles wird gut.<br>
Der olsr-Traffic sollte meiner Meinung nach von TOS-Bits ausgenommen<br></blockquote><div> </div><div>netter gedanke (kategorie: 'alle jahre wieder ,..'), <br>allerdings,....</div><div><br></div><div>olsrd muesste imho den traffic/auslastung unabhaengig vom packetloss des links messen, (und bitrate sollte er auch noch wissen,..)<br>
die beiden (oder gar alledrei) sachen zusammen zu messen/behandlen ist imho zu "problematisch",..</div><div><br></div><div>beispiel:</div><div><br></div><div>packetloss steigt rasant an -> olsr sollte schnell auf eine andere route umsteigen (potentiell ohne allzuviel darauf ruecksicht zu nehmen ob die nachbarn mit den aenderungen auch nur ansatzweise 'synchronisert' gleichziehen)<br>
<br></div><div>hingegen: traffic steigt (rasant an (z.b. von idle auf voll ausgelasteten link)) an -> olsrd sollte dann evt. prinzipill mal abwarten ob das nur ein kurzer spike ist,.., und wenn nicht, dann die route (und vorher die linkkosten) in aller ruhe umbauen (und auch dann ist es alles andere als einfach daruaf richtig zu reagieren)</div>
<div><br></div><div>denn wenn ein link funktechnisch schlecht ist, bedeutet das wechseln auf einen anderen link, idr nicht das dieser dann auch "schlecht" wird,..</div><div><br></div><div>hingegen wenn ein link ausgelastet, und man wechselt, ist potentiell dann sofort der andere dann (auch) ausgelastet,. (und pot. der alte nicht mehr)<br>
-> die routen wechseln andauerd hin und zrueck, <br><br></div><div>und ausser packet reordering, mehr olsrd-overhead, der zeitweisen verweundung einer eigentlich schlechteren route, und im worst case kurze loops (also packetloss), ist nix gewonnen,..</div>
<div>---------</div><div>hauptziel sollte sein mal ein bzgl. QOS, conntrack, wifi-settings moeglichst einheitliches netz zustandezubringen,.. (und fürs erste mal die alte freifunkfirmware 'nachzubauen')</div><div>
<br></div><div>dann (bzw. paralell dazu) neue metriken/QOS settings in testnetzen testen,..<br>(evt auch mal wirklich versuchen einmesh mit multi-path-routing zu bauen)</div><div><br></div><div>und dann diese neuerungen wenn sie denn funktioneren, möglichst flächendeckend im produktiv netz deployen,..</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">(Ganz zu schweigen von korrekten Information über Signal,<br>
Noise, aktuelle Rate usw.)<br></blockquote><div>hmm also das sollten sie eigentlich alle weitaus besser als die alten reporten,..</div><div>(nur eben über netlink und nit mehr ueber die alten ioctls,..) </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Wäre mal interessant, eine Intel WLAN-Karte da mitspielen zu lassen. Leider<br>
läuft der Treiber auf einem Routerboard nicht...<br></blockquote><div>gottseidank,.. *G </div><div><br></div><div>lg Markus </div></div>