[Berlin-wireless] "airtime" RX u/o TX?, war:horst 1.3 prerelease - bitte testen!
Sven-Ola Tücke
sven-ola
Mo Nov 12 08:10:27 CET 2007
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
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname : horst.patch
Dateityp : text/x-diff
Dateigröße : 9518 bytes
Beschreibung: nicht verfügbar
URL : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20071112/c727ec86/attachment.patch>
Mehr Informationen über die Mailingliste Berlin