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

bruno randolf br1
So Nov 11 07:28:49 CET 2007


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






Mehr Informationen über die Mailingliste Berlin