[Wien] missing QOS

[Markus Kittenberger]

2011/12/10 Adi Kriegisch <(spam-protected)>

> Hallo!
>
> >      Da ist auch ein (minimales) tc setup drinnen... damals hat's nichts
> >      gebracht, weil ein "feature" von madwifi alle tc settings umgangen
> hat,
> >
> >    ich fürchte derartige "features" gibts idr weiterhin,..
> >    (was eigene queues in tc zu konfigurieren bei wifi interfaces
> weiterhin
> >    ... macht)
> >    da eben die treiber inzwischen interne queues haben, (und sich das
> wohl
> >    auch nit mehr aendern wird *G)
> Also ich dachte für den Anfang erst mal an etwas wie das hier:
>  | tc qdisc add dev wifi0 root sfq perturb 10

(für alle Interfaces des Routers wird der FIFO-Algorithmus durch
> "Stochastic Fair Queueing" ersetzt).
>
> Die vorhandenen Queues in den Treibern werden die "neue" Reihenfolge der
> Pakete (durch SFQ) imho höchstens minimal verändern.

potentiell aber auch komplett,

> Der erwünschte Effekt
> -- nämlich interaktive oder kurzlebige Verbindungen fairer zu behandeln --
> ist so auf jeden Fall mal gegeben.
>
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)

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

>
> Wenn man das noch in ein schönes Extrapaket packt und mit einer eigenen
> Konfiguration versieht, haben wir mal etwas mit dem wir loslegen können.
> (Die Firewall muss eh extra gepatched werden, damit da auch korrekte
> NOTRACK-Regeln erzeugt werden)
>
> >    dafür sollten (alle?) 802.11 treiber jedoch das skb->priority feld
> >    honorieren, d.h. darüber ist deren eigene (üblicherweise basierend
> auf TOS
> >    bits) packet klassifiziereung (in die treiber-eigenen queues)
> >    overrule-able,..
> Wenn sie das tun, super!

evt hast mich falsch verstanden, (auch weil du unten für OLSR pakete die
TOS bits nicht aendern wolltest, für DNS aber schon,..)
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,..))

(ausser evt. wenn alles andere scheitert, könnte man darüber dann doch
nachdenken)

> Dann setzen wir passende Flags für DNS in der
> Firmware und alles wird gut.
> Der olsr-Traffic sollte meiner Meinung nach von TOS-Bits ausgenommen
>

netter gedanke (kategorie: 'alle jahre wieder ,..'),
allerdings,....

olsrd muesste imho den traffic/auslastung unabhaengig vom packetloss des
links messen, (und bitrate sollte er auch noch wissen,..)
die beiden (oder gar alledrei) sachen zusammen zu messen/behandlen ist imho
zu "problematisch",..

beispiel:

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)

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)

denn wenn ein link funktechnisch schlecht ist, bedeutet das wechseln auf
einen anderen link, idr nicht das dieser dann auch "schlecht" wird,..

hingegen wenn ein link ausgelastet, und man wechselt, ist potentiell dann
sofort der andere dann (auch) ausgelastet,. (und pot. der alte nicht mehr)
 -> die routen wechseln andauerd hin und zrueck,

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,..
---------
hauptziel sollte sein mal ein bzgl. QOS, conntrack, wifi-settings
moeglichst einheitliches netz zustandezubringen,.. (und fürs erste mal die
alte freifunkfirmware 'nachzubauen')

dann (bzw. paralell dazu) neue metriken/QOS settings in testnetzen testen,..
(evt auch mal wirklich versuchen einmesh mit multi-path-routing zu bauen)

und dann diese neuerungen wenn sie denn funktioneren, möglichst
flächendeckend im produktiv netz deployen,..


(Ganz zu schweigen von korrekten Information über Signal,
> Noise, aktuelle Rate usw.)
>
hmm also das sollten sie eigentlich alle weitaus besser als die alten
reporten,..
(nur eben über netlink und nit mehr ueber die alten ioctls,..)

> Wäre mal interessant, eine Intel WLAN-Karte da mitspielen zu lassen. Leider
> läuft der Treiber auf einem Routerboard nicht...
>
gottseidank,.. *G

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