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

Horst Krause offlinehorst
Fr Nov 9 21:05:53 CET 2007 

hallo bruno, sven-ola + liste,

vorab vielen dank für ideen + coden des [horst2.0]-tool,
da werden nun much_more_infos geboten als vorher.

es steht auch schon bei sven-ola aufm server, oder für
deppen_wie_mich:
 fff-web-IF/verwalten/software2/horst

ich grüble noch an einer sinnvollen definition/gebrauch
der mir unklaren begriffe "Usage" u. "Airtime"
im [horst2.0]_option"a" = Packet-Statistik-Fenster.

Airtime (Wikipedia),
- .. Schwerelosigkeitsgefühl beim Achterbahnfahren..
  # mir ist zwar etwas dissy, aber det isset nich :-))
- Airtime ist auch der englische Begriff für Sendeplatz.
# aha, hier: "airtime" = t_TX.

google [airtime], 1.hit,
  http://www.at-mix.de/airtime.htm
 Telekommunikation-Fachbgriffe:
 "Als Airtime bezeichnet man die Zeit,
  in der Sie via Mobilfunk ein Gespräch führen
  - in der sie also selbst anrufen oder angerufen werden.
  Airtime stellt die Abrechnungsgrundlage zwischen allen
  beteiligten Geschäftspartnern im Mobilfunkmarkt dar."
# oha, hier: "airtime" = t_TX + t_RX

# sven-ola's mail (s.u.) verstehe ich so, dass es sich um
  die anteilige TX-zeit für eine packet-art an der
  gesamt-TX-zeit handelt?

evt. nach folgender formel?
> > >    die belegte "Luftzeit%" 
> > >    also, bytes * rate = time anzeigen ...
# hmm, das ist eine zeit, 
  wenn luftzeit%, dann von was als 100% gesammt?

nun knirscht irgendwas bei mir im kopf:
-----------------------------------------------------------------
1) [horst]-tool empfängt nur, sendet selber nix,
   also ist es eine RX-statistik, oder?
2) t_RX = t_gesamt - t_TX
   # mit t_TX = min. adhoc-beacons u. olsr/bat-protokoll-foo
                (+ evt. payload) 
   denn, wenn node sendet, kann er nix empfangen.
   also müsste doch irgendwo meines node's t_TX eingerechnet sein.
3) mein t_TX schwankt zudem evt. sehr stark, hmm...

handelt_es_sich / wäre_es_sinnvoll, statistik zu machen aus sicht
- des node-TX
- des node-RX
- eines *neutralen* luft-beobachter ausserhalb (m)eines node?   

??????????????????????? Packet Statistics????????????????????????????
?                                                                  ?
? Packets: 23076                        bit/sec: 52.8k (54120)             ?
? Bytes:   5.9M (6193287)               Usage:   1.5% (14578)              ?
? Average: ~268 B/Pkt                                                      ?
?                                                                  ?
? RATE      Packets    Bytes ~B/P  Pkts% Byte% "AirTime%"                  ?
? ------------------------------------------------------------------------ ?
?    1M        7756   750.2k   99  33.6  12.4  55.0  ***********           ?
?    2M         386    73.2k  194  1.7   1.2   2.7   *                     ?
?    5M        6545     1.2M  194  28.4  20.6  18.3  ***                   ?
?    6M         111     3.0k   28  0.5   0.1   0.0   *                     ?
?   11M        6047     2.9M  505  26.2  49.4  19.9  ****                  ?
?   12M        1467    28.6k   19  6.4   0.5   0.2   *                     ?
?   18M         764   962.1k 1289  3.3   15.9  3.9   *                     ?
?                                                                  ?
? TYPE      Packets    Bytes ~B/P  Pkts% Byte% "AirTime%"                  ?
? ------------------------------------------------------------------------ ?
?   DATA       8398     5.0M  631  36.4  85.6  43.5  *********             ?
?   PROBRQ      117     6.5k   56  0.5   0.1   0.5   *                     ?
?   NULL        111     3.0k   28  0.5   0.1   0.0   *                     ?
?   PROBRP      218    20.5k   96  0.9   0.3   1.4   *                     ?
?   BEACON     7371   725.6k  100  31.9  12.0  53.2  ***********           ?
?   RTS        4040    78.9k   20  17.5  1.3   0.4   *                     ?
?   DEAUTH        1       30   30  0.0   0.0   0.0   *                     ?
?   CTS          97     1.3k   14  0.4   0.0   0.0   *                     ?
?   ACK        2723    37.2k   14  11.8  0.6   0.4   *                     ?
?                                                       ???????????????????????????????????????????????????????????????????

erklärt mir bitte mal "Usage" und "Airtime%" in diesem zusammenhang,
oder wenn bei euch auch klärungs-bedarf besteht,
was machen wir denn draus...

vielleicht hilfts ja schon, es in "TX_on-air_time", o.ä. um zu benennen,
wenns das wäre.

wenns RX-usage/airtime wäre, sollte es auch so benannt sein.


  gruss horst_104.131.10.1
  offlinehorst at web.de




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