[Berlin-wireless] "airtime" RX u/o TX?, war:horst 1.3 prerelease - bitte testen!

[Sven-Ola Tücke]

Noch Nachsatz: Bei der Schritt-Tabelle faellt natuerlich sofort auf, dass bei 
1 Mbit mit 4 Bit / Schritt gearbeitet wird. Es gibt z.B sowas wie 0.5 Mbit 
mit 2 Bit / Schritt. Nach meiner Kenntnis im Madwifi das XR-Feature fuer 
Extra-Reichweite bei Extra-Langsam...

// Sven-Ola 

Am Montag 12 November 2007 08:10:27 schrieb Sven-Ola Tücke:
> Moin Bruno,
>
> hab' am WE ein bisschen mit der aktuellen Horst-Version gespielt. In dem
> beigefuegtem Patch findest du ein paar Kosmetiksachen sowie einen mit
> #ifdef geklammerten Aenderungsansatz fuer die Airtime-Statistik (aktiv bei
> "make SVEN_OLA=1"). Das ist noch nicht 100% funktional und muss noch
> diskutiert werden, darum das #ifdef.
>
> Deine Implementation der Airtime-Stats zeit die _relativen_
> Paket-Haeufigkeiten an. Das ist erstmal OK - gerade weil das Horst Tool
> auf'm WRT erheblich Pakete verpasst. Ein Vergleich zwischen dem Tool und
> einem simplen "tcpdump -ni prism0 -w bla.cap" auf einem WRT mit der Luft
> unter ordentlich Last zeigt ca. 600kb fuer Horst aber 3,5mb fuer tcpdump.
>
> Es braucht also entweder eine Lese-Puffer-Kette, die beim Update der
> Anzeige oefters mal gefuellt wird oder wenigstens ein "-r
> infile.cap"-Feature. Auf einem Laptop mit ausreichend CPU (und einer
> Madwifi-getriebenen Karte) gibt es kaum verpasste Pakete - hier bekomme ich
> eine einigermassen realistische Anzeige.
>
> Ich moechte naemlich eine _absolute_ Darstellung haben. Und da fehlt noch
> der Balken fuer "unbenutzte / freie / verschwendete / verpasste" Luftzeit.
> Damit der nicht negativ wird (oder unrealistisch grosz) muss noch
> nachkorrigiert werden. Einerseits braucht jeder Frame eine bestimmte
> Interframe-Wartezeit. SIFS fuer Data und DIFS fuer ACKs, wobei ein
> Mittelwert ausreichend sein sollte (bereits realisiert: grep
> EXTRATIMEPERFRAME). Und andererseit muessen die
> Datenuebertraguns-Bitgroeszen-Rundungsfehler beruecksichtigt werden.
> Letzteres habe ich hilfsweise mit EXTRABYTEPERFRAME eingebaut. Kommt etwa
> hin. Bei 2 WRTs die ordentlich in die Luft blasen und eine Madwifi auf
> meinem Laptop als Monitor. Dann mit verschiedenen Uebertragungsraten
> und/oder Paketgroessen spielen.
>
> Zu den Rundungsfehlern hier mein "Erkenntnis-Stand". Man lernt ja nie aus
> :)
>
> Jedes Paket aus dem Monitor-Interface ist in der Luft sowieso 2 Byte
> laenger (die FCS fehlt). Ein ACK-Paket ist z.B 14 Byte in der Luft, das
> prism0 bzw. ath-monitor rueckt aber nur zwoelf 'raus. Und alle
> Wireless-Hardware arbeitet mit einer festen "Schrittgeschwindigkeit" (bzw.
> Symbolrate) von 125.000 Schritten/Symbolen pro Sekunde. Das'n bisschen wie
> bei WCDMA, hier gibs die bekannten MCHIP/sek. Diese Schrittgeschwindigkeit
> bleibt immer gleich, aber pro Schritt werden unterschiedlich viele Bits
> uebertragen. Nach folgender Tabelle:
>
> 1 Mbit == 4 Bit / Schritt		12 Mbit == 48 Bit / Schritt
> 2 Mbit == 8 Bit / Schritt		24 Mbit == 96 Bit / Schritt
> 5.5 Mbit == 20 Bit / Schritt	36 Mbit == 144 Bit / Schritt
> 6 Mbit == 24 Bit / Schritt		48 Mbit == 192 Bit / Schritt
> 11 Mbit == 44 Bit / Schritt		54 Mbit == 216 Bit / Schritt
>
> Dadurch gibts Rundungsfehler, die sich erheblich aufsummieren koennen.
> Beispiel: Unser ACK-Paket ist 14 Byte == 112 Bits. Man kann es bei 54 Mbit
> in einem Schritt uebertagen. Dabei werden aber 104 Bits "verschwendet". Das
> ist auch der Grund, warum ein ACK normalerweise mit der 36er Rate
> uebertragen wird (ist jedenfalls bei den Broadcom-Wifi's so). Dieser ganze
> Sermon muss fuer die Airtime-Statistik noch umgesetzt werden.
>
> // Sven-Ola