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

Mo Nov 12 08:41:28 CET 2007

hi sven-ola!

danke! und erstmal nur kurz zu den verlorenen paketen, bis ich zeit habe mir 
das mit der airtime genau anzusehen: ich habe am PC auch viele pakete 
verloren bis ich die sleep time im receive loop verkuerzt habe. die kann man 
mit -w <usec> an der command line veraendern. vielleicht braucht der wrt da 
noch ne kuerzere zeit. hast du damit rumgespielt? wenn das nicht reicht 
koennte ich mal select() ausprobieren. lese-puffer waer schoen, aber wie???

lg,
bruno

On Monday 12 November 2007 16:10:27 Sven-Ola Tücke wrote:
> 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
>
> Am Sonntag 11 November 2007 07:28:49 schrieb bruno randolf:
> > hallo horst und allerseits!
> >
> > ja, der begriff "AirTime" ist erst mal nicht sofort intuitiv verstehbar,
> > und etwas schwammig, deshalb steht er auch in anfuehrungszeichen (oder
> > sagt ihr deutschen "hochkomma"? ;)). ueber die begriffswahl und genauere
> > definitionen kann und sollte man diskutieren. ich schreib das u.a. auch
> > um das fuer mich nochmal klar zu kriegen ;)
> >
> > folgende ueberlegung steht hinter der "AirTime":
> >
> >
> > 1) erstmal ist es egal ob TX oder RX. natuerlich ist [horst] ein rein
> > passives tool, das nur empfaengt was im medium (in der luft) ist. aber
> > das was ich empfange hat auch mal wer gesendet, waerend ich empfange kann
> > ich nicht senden und umgekehrt - es geht also darum was im medium LUFT
> > passiert, und um die belegung dessen. genauer gesagt geht es darum was
> > [horst] davon SIEHT was im medium passiert.
> >
> >
> > 2) wenn alle mit einer rate von 1Mbit senden, koennen insgesamt 1Mbit pro
> > sekunde uebertragen werden.
> >
> > wenn alle mit einer rate von 54Mbit senden, koennen insgesamt 54Mbit pro
> > sekunde uebertragen werden.
> >
> > zum senden eines pakets mit 1500 Byte brauche ich bei 1Mbit/sec
> >   1500 * 8 / 1000000 = 0.012 sekunden
> >
> > zum senden des selben pakets bei 54 Mbit/sec
> >   1500 * 8 / 54000000 = 0.0002 sekunden
> > (was wieder erwarten 54 mal so schnell ist..:))
> >
> > und genau diesen zusammenhang drueckt die AirTime aus. dh.
> >   AirTime (eines pakets) = PaketLaenge in Bit / PhysicalRate
> >
> > es ist also die dauer, wie lange der KANAL, das MEDIUM, die LUFT belegt
> > wurde, also eigentlich die UEBERTRAGUNGSZEIT (Sendezeit = Empfangszeit).
> >
> > man kanns auch so sehen:
> > AirTime ist die uebertragungszeit normiert auf 1Mbps.
> >
> > (in wirklichkeit ist das eine vereinfachung aber dazu spaeter, in 5))
> >
> >
> > 3) AirTime% ist die AirTime einer Paketart im Verhaeltnis zu allen
> > anderen AirTimes, dh. wieviel % der gesamt genutzten AirTime gehen zum
> > senden einer bestimmte paketart drauf.
> >
> > > RATE      Packets    Bytes ~B/P  Pkts% Byte% "AirTime%"
> > > ? ?
> > > -----------------------------------------------------------------------
> > >- ?  1M        7756   750.2k   99  33.6  12.4  55.0  *********** ? 11M  
> > >      6047     2.9M  505  26.2  49.4  19.9  ****
> >
> > und das ist das perfekte beispiel dessen was wir damit zeigen wollen.
> >
> > 7756 pakete mit einer rate von 1M haben insgesamt nur 750.2 KiloByte
> > daten uebertragen (12.4% aller gesamt uebertragenen Bytes), damit aber
> > 55% der AirTime verbraucht.
> >
> > andererseits wurden bei 11M insgesamt 2.6 MegaByte, also 49.4% aller
> > daten uebertragen und dabei nur 19.9% AirTime verbraucht.
> >
> > > TYPE      Packets    Bytes ~B/P  Pkts% Byte% "AirTime%"
> > > -----------------------------------------------------------------------
> > >- ? ? DATA       8398     5.0M  631  36.4  85.6  43.5  ********* ?
> > > BEACON     7371   725.6k  100  31.9  12.0  53.2  ***********
> >
> > auch hier. man sieht dass in deinem netz hauptsaechlich beacons
> > uebertragen werden. es sind zwar nicht viele Bytes, aber trotzdem 53.2%
> > der belegung des mediums. im gegesatz dazu hast du die grosse mehrheit
> > der daten (85.6% aller bytes) in weniger zeit versendet.
> >
> > Die AirTimes hier sind immer im Verhaeltnis zu allen anderen Paketen,
> > d.h. wenn du in 1 minute nur 2 gleich grosse pakete bei gleicher rate
> > empfaengst, haben beide 50% airtime, den rest der zeit ist das medium
> > frei.
> >
> >
> > 4) Usage soll genau das anzeigen, also die AirTime im Verhaeltnis zur
> > gesamt verfuegbaren AirTime. die muss aber noch finegetuned werden, denn
> > ich habe es nie geschaft 100% zu erreichen.
> >
> >
> > 5) das ganze ist nur eine annaeherung. in wirklichkeit gibt es abhaenging
> > von der rate und modulierungsmethode kleine unterschiede in den pausen
> > die zwischen den paketen eingehalten werden muessen (inter frame spaces),
> > ausserdem gibt es die "virtuelle kanalbelegung" mit RTS/CTS und dem
> > duration feld im 802.11 header (NAV network allocation vector) und die
> > exponentiellen backoffs... das sind details um die ich mich momentan
> > nicht kuemmern wollte. die CTS/RTS und duration koennten noch interessant
> > sein einzubauen, die frame spaces sind relativ irrelevant, glaube ich.
> >
> >
> > in jedem fall ist das mal ein 1. versuch in die richtung. weitere ideen,
> > bessere namensgebung und verifizieren der algorithmen im code (die sind
> > evtl noch etwas ineffizient) waeren sehr gerne gesehen.
> >
> > bruno
> >
> > > On Tue, 30 Oct 2007 20:41:56 +0100
> > >
> > > Sven-Ola Tücke <sven-ola at gmx.de> wrote:
> > > > N'abend Horst,
> > > >
> > > > Lust auf Grundsätzliches ?-) Mit Luftzeit (dt. für Airtime) meine ich
> > > > die insgesamt zur Verfügung stehende Sendezeit. In einer Sekunde
> > > > können ja nur eine bestimmte Bytezahl bei einem bestimmten
> > > > Übertragungstempo gesendet werden. Wenn 20% der Zeit bereits von
> > > > Beacons + ACK-Paketen belegt sind, ist es ratsam z.B. die OLSR und
> > > > Batman-Pakete nicht unbedingt auf 1Mbit nochmal 25% verbrauchen zu
> > > > lassen. Das meine ich mit "Luftzeitbelegung". Und das zeigt
> > > > (hoffentlich) das Horst-Tool zukünftig an. Und darum ist der Default
> > > > für die Broadcast-Rate mit der Freifunk-Firmware > 1.6.0 auf 5.5 Mbit
> > > > eingestellt. Ausgehend von der Annahme, dass man ja immer noch
> > > > 'runterdrehen kann, aber die Mehrheit besser weniger "Luftzeit"
> > > > verbrauchen sollte.
> > > >
> > > > Richtig ist außerdem: sowohl OLSR als auch Batman benutzen zur Zeit
> > > > ETX AFAIK. Die Packetverlust-Messung ist suboptimal, weil
> > > >
> > > > a) bei Batman die "Meßpakete" unrealistisch klein sind
> > > >
> > > > b) allgemein bei niedriger Sendrate gemessen wird, um eine
> > > >     höhere Reichweite für die Routing-Infos zu haben bzw. um
> > > >     weiter entfernte Stationen auch noch einzubinden.
> > > >
> > > > c) für eine realistische Messung auf der IP-Ebene die ganze
> > > >     Bandbreite aufgebraucht würde.
> > > >
> > > > Darauf gibt's keine generell 'richtige' Antwort. Man kann anfangen
> > > > mit Wifi-Treibern herumzuspielen und deren Meßwert-Daten
> > > > einzukalkulieren. Der Meßfehler ist jedenfalls da und spürbar.
> > > >
> > > > Besser wird es möglicherweise mit dem ETT-Ansatz.
> > > > Expected-Transmission-Time ist ein anderer Algorithmus als ETX - der
> > > > genau diese Senderate
> > > > berücksichtigen könnte. Da Elektra das mal in den Mund genommen hat
> > > > gehe ich davon aus, das unsere Batmannen das bereits wissen und eines
> > > > Tages realisieren. Angucken kann man sich das heute schon. Mit einem
> > > > klitzekleinen aber süßen Programm: "bing". Bing ermittelt die
> > > > Bandbreite einer Verbindung anhand von Laufzeit-Differenzen
> > > > unterschiedlich großer Pings.
> > > >
> > > > P.S.: Das sich der Flattermann hin und wieder zur DOS-Attacke mauert
> > > > sind mit sicherheit in erster Linie Implementierungsprobleme. Sowas
> > > > dauert. Zu OLSR kann ich sagen: so langsam könnte es soweit sein,
> > > > dass es wirklich einigermaßen funktioniert. Hat ja auch 2 Jahre
> > > > Vorsprung <ggg>
> > > >
> > > > Schönen Abend noch,
> > > > // Sven-Ola
> > > >
> > > > Am Dienstag 30 Oktober 2007 14:26:43 schrieben Sie:
> > > > > hallo sven-ola,
> > > > >
> > > > > definiere mir bitte mal "Luftzeit", bzw. "airtime".
> > > > >
> > > > > licht-geschwindigkeits-packet-flugzeit ist es wohl nicht.
> > > > >
> > > > > meintst du damit den anteil einzelner packet-arten/speeds an der
> > > > > TX-dauer, oder div. anteile der
> > > > > empfangenen/decodierten_packet-arten an der RX-zeit?
> > > > >
> > > > > RX-*sturm*, (# ich meine hier nicht RX-*taub-brüllen*)
> > > > > u. in folge auch ap-cpu-overload gabs in nieder-f'hain
> > > > > flächendeckend vor ca. 2 wochen durch eine wildgewordene
> > > > > flattermouse.
> > > > > mein wrt war zäh wie leder, ping von läppi über eth: 1s ~ 7s ...
> > > > > unter noerds nennt man sowas wohl DOS-attacke, wenn gewollt.
> > > > >
> > > > > bei der gelegenheit will ich auch dich mal fragen, warum
> > > > > unrepräsentative udp/lowspeed-ETX-packets zur routenwahl
> > > > > benutz werden.
> > > > >
> > > > > und warum man diesen -imho- mainbug jetzt auch auf die batfrauen
> > > > > in form des 'originator-counts' als feature übernimmt.
> > > > >
> > > > > zum 'vorfühlen', was möglich ist, oder 'nachmessen' wenns klemmt
> > > > > sind solche *robusten* packets gold wert, weil sie die digitale
> > > > > geht/nicht-charakteristik etwas auf-fuzz-eln.
> > > > >
> > > > > aber als basis des routing-algorithmus kann es zu routen führen,
> > > > > durch die real-life-netto-payload evt. nicht durchkommt.
> > > > >
> > > > > gruss horst_104.131.10.1
> > > > > offlinehorst at web.de
> > > > >
> > > > >
> > > > >
> > > > > On Wed, 24 Oct 2007 12:33:43 +0200
> > > > >
> > > > > "Sven-Ola Tuecke" <sven-ola at gmx.de> wrote:
> > > > > > Aber hallo Bruno,
> > > > > >
> > > > > > ja ist denn schon Weihnachten? Darf ich mir was wuenschen? Eine
> > > > > > kleine Statistik, mit 2 Torten oder Balkendiags:
> > > > > >
> > > > > > 1: empfangene Wifi Frames nach Typ, etwa
> > > > > >     (typ 4-probereq sind 10%, typ 32-data sind 30%)
> > > > > >
> > > > > > 2: empfangene Wifi Frames nach Speed, etwa
> > > > > >     (10% auf 1mbit, 20% auf 5.5mbit etc am besten
> > > > > >    die belegte "Luftzeit%" -also bytes*rate=time anzeigen)
> > > > > >
> > > > > > Man kann's mit Wireshark machen, ist aber einige Handarbeit. So
> > > > > > kann man z.B. einen Probe-Response-Storm entdecken (auf Events,
> > > > > > wo viele Leute irgendwelche Gadgets haben, senden *alle* AdHoc
> > > > > > Stationen Probe-Antworten -> 50 Gadgets * 50 Nodes => 2500
> > > > > > ProbeResponses/Sekunde und
> > > > > > Ende-Gelaende)
> > > > > >
> > > > > > // Sven-Ola
> > > > > >
> > > > > > ----- Original Message -----
> > > > > > From: "bruno randolf" <br1 at einfach.org>
> > > > > > To: "wirelesslan in Berlin" <berlin at berlin.freifunk.net>
> > > > > > Sent: Wednesday, October 24, 2007 12:10 PM
> > > > > > Subject: [Berlin-wireless] horst 1.3 prerelease - bitte testen!
> > > > > >
> > > > > >
> > > > > > hallo allerseits!
> > > > > >
> > > > > > ich habe mich mal des seit 2 jahren maintainer-losen "horst"
> > > > > > tools angenommen,
> > > > > > die in der zwischenzeit von sven-ola und robert gebastelten
> > > > > > patches eingebaut
> > > > > > und ein paar weitere verbesserungen gemacht: es wird nun
> > > > > > automatisch erkannt ob beim monitor interface ein radiotap oder
> > > > > > prism2 header verwendet wird, und
> > > > > > ich habe ein neues fenster 'e' zum auflisten alles ESSIS
> > > > > > eingebaut, incl. automatischer ESSID split detection... und ne
> > > > > > menge kleinigkeiten...
> > > > > >
> > > > > > es ist noch nicht ganz fertig, aber fast, und ich wuerde es jetzt
> > > > > > gerne mal auf einer anderen platform und mit anderen wlan
> > > > > > chipsets testen - ich selbst kann hier leider grade nur auf
> > > > > > atheros/x86 basis testen (hab mein cube passwort vergessen, und
> > > > > > keine serielle... argl...)
> > > > > >
> > > > > > also fuer die mutigen, hier ungetestete pakete fuer kamikaze
> > > > > > trunk wrt: 
> > > > > > http://br1.einfach.org/horst/horst_1.3pre-1_mipsel-wrt.ipk cube:
> > > > > > http://br1.einfach.org/horst/horst_1.3pre-1_mipsel-mtx.ipk
> > > > > >
> > > > > > den source gibts per
> > > > > >   git clone git://br1.einfach.org/git/horst.git
> > > > > >
> > > > > > und hier noch als download:
> > > > > >   http://br1.einfach.org/horst/horst-1.3pre.tgz
> > > > > >
> > > > > > und es gibt ein git-web interface :)
> > > > > >   http://br1.einfach.org/gitweb?p=horst.git;a=summary
> > > > > >
> > > > > > hier die openwrt build files
> > > > > >   http://br1.einfach.org/horst/horst-openwrt.tgz
> > > > > >
> > > > > > also, wuerde mich freuen wenn das jemand auf nem wrt und/oder
> > > > > > cube ausprobieren kann... interessant waere vor allem ob die SNR
> > > > > > auswertung auf nicht-madwifi karten noch stimmt, und ob die TSF
> > > > > > anzeige stimmt oder bytes geswapped werden. bugreports bitte an
> > > > > > mich.
> > > > > >
> > > > > > lg aus japan,
> > > > > > bruno
> > > > > > _______________________________________________
> > > > > > Berlin mailing list
> > > > > > Berlin at berlin.freifunk.net
> > > > > > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin
> > > > > >
> > > > > > _______________________________________________
> > > > > > Berlin mailing list
> > > > > > Berlin at berlin.freifunk.net
> > > > > > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin