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

Mo Nov 12 22:42:37 CET 2007

hallo bruno, dirk, sven-ola + liste,

thanks for this lots of infos,
das sind ja inzwischen standard-werke zum thema geworden.

die definition von "AIR-TIME" ist also noch 
"work_under_progress", tut aber not, wo mir dies hit-word
in den letzten wochen öfter aus dem busch entgegen schallte.

also mal auf niederdeutsch, gewissermassen zum anfassen
(bei gegebener c_0 = lichtgeschwindigkeit in der radio-link-'röhre'):
 PHY-RATE sagt, wie gross ist der durchmesser meines link-'rohr', und
 USAGE sagt, wie voll das 'rohr' insgesamt ist; und
 AIR-TIME%, welchen anteil davon einzelne paket-typen haben.

apropo rohr, ich hab zu beginn der frischen jahreszeit mal
meinen oszillophanten angeheizt, zwecks in_die_röhre_kucken...
dazu anbei die ättätschments:
 "[ping -s 50000]"
   zeigt sehr schön, wie es in kleinere einheiten zerlegt wird.
 "end-ping.. + reply"
   für die analoge fraktion (# das 'kleine' rechts ist -imho-
   der erhebliche ping-reply-'nachlauf'(?) der gegenseite; und
 "ping.. + pckt-stats"
   für die virtualisten.

die oszi-screens zeigen auf der horizontal-achse einen ausschnitt
von einem ad-hoc-beacon-abstand = 1/10-tel-sec = 100ms
während des [ping -s 50000] von 600ms bis xxxxms dauerte,
je nach luft-lage/funk-wetter :-)

der schleppi(als monitor)-[horst"h"+"a"]-screenshot ist während
dem [ping -s 50000] gestartet; zeigt also die packet-history und
-statistik für einen 1hop-radio-link (ohne 'leerlauf').

irgendwie ist das für mich alles noch sehr böhmisch.
die "usage", etc. will kaum hochgehen, obwohl beim ping
sicher was zurück-kommt.
aber ich wollte mal was von der "grob-mechanischen" seite
zum thema "AIRTIME" beitragen, dass sich aber auch ohne
meine klugscheisserei ganz ordentlich entwickelt hat.

nun noch die kopfnuss des tages:
-------------------------------------------------------------------
seit der chaos-theorie weiss ich davon, das alles eine frage
der scalierung ist.

mal angenommen, ich betrachte nur einen zeitraum von [100ms];
(es geht auch mit jedem anderen, aber den hab ich aufm schirm)
und weiter angenommen, mein TX tx-tet dauernd während dieser zeit,
was sagt dann eure packet-statistik?

-imho- sollte sie dann besser nüschts statistikern, weil
viel repräsentatives kann der RX nicht empfangen haben,
während mein TX an war.
-------------------------------------------------------------------

zum schluss noch zwei weitere randbedingungen / grausamkeiten als
life-mitschnitte des hinterhof-wlan-alltags, siehe die ättätschments:
 "klotz-zyklen"
   hier der [mtr] oben rechts, und der
 "µ-wave-oven"
   meiner nachbarin, die ~ 50% luft-raum belegt, wenn sie heiss ist.
   (die µ-welle natürlich  :-)  )

gruss horst_104.131.10.1
offlinehorst at web.de

On Sun, 11 Nov 2007 12:22:10 +0100
dirk <tigger at lipsia.de> wrote:

> bruno randolf schrieb:
> 
> > 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), 
> 
> Die Abhängigkeit in Bezug auf die IFS wird nicht durch die Modulation
> vorgegeben sondern durch das eingestellte 802.11g Frameformat/
> Betriebsmodi:
> 
> * reines OFDM: der Header selbst bereits als OFDM-Symbole
> 
> * DSSS/OFDM: der Header ist für 802.11b Devices lesbar
> bedeutet das erst ab MAC (PSDU) mittels OFDM übertragen werden, Präamble
> und phy-Header (PLCP)  werden mittels DSSS übertragen. Zu unterscheiden
> ist dabei auch noch ob verkürzte Präamble & Header genutzt wird.
> 
> Dieser kleine Unterschied bedeutet ob mein Nettodurchsatz 14,4Mbit/s
> oder 24,4Mit/s beträgt.
> 
> Was man nun als Vernachlässigbar abstuft kann man IMHO erst entscheiden
> wenn man weiß was man mit der "Airtime" bezwecken will...letztlich ist
> ja eine Übertragung rein störrisch bei TCP/IP erst nach dem
> erfolgreichen ACK beendet. Und selbst wenn man dies auf 802.11 reduziert
>  sollte dort auch das entsprechende ACK noch abgewartet werden. Bleibt
> das ACK aus handelt es sich um Packetloss.Dann wird das Paket nach
> DIFS+Backoff und CCA-Medium-frei-Meldung nochmal gesendet
> 
> Interessant wäre über die "Airtime" Rückschlüsse auf das Paketloss der
> 802.11 Pakete zu ziehen. Dies setzt jedoch vorraus das Paketgröße und
> das genutzte Übertragungsverfahren bekannt ist. Aber ob dies so einfach
> ist weiß ich nicht.
> 
> Einen guten Überblick über die Zeitverhältnisse und
> Brutto/Netto-Datenraten sind in dem Buch von J.Rech: "wireless LANs" zu
> finden.
> 
> Ein Beispiel daraus exemplarisch für 802.11b 11Mbit/s (Zeit in
> Mikrosekunden)
> 
> 18 Byte Präamble 1Mbit/s = 144ys
> 6 Byte PLCP 1Mbit/s = 48ys
> 34 Byte MAC&FCS 2Mbit/s = 136ys
> 48 Byte LLC/SNAP/TCP/IP 11Mbit/s = 34,91ys
> 1460 Byte Payload = 1061,82ys
> IFS = 10ys
> Summe 1434,73ys
> 
> ACK des 802.11 = 258ys
> 
> ACK des TCP/IP = 372,91ys
> (nur kommt dies ACK eben vom IP-Host und nicht vom WLAN-Host)
> 
> ACK 802.11 für das ACK des TCP/IP = 258ys
> 
> Gesamt macht dies Nettodurchsatz 5,02Mbit/s was natürlich in der
> multihop-Umgebung auch nicht realistisch wird...
> 
> Wer dies nun für OFDM ausrechnen will: ein 54Mbit OFDM Symbol codiert je
> 216 DatenBits und hat eine Übertragungsdauer (inkl.Guard-Intervall) 4 ys
> (48Mbit = 192Bits, 36 = 144, 24 = 96, 18 = 72, 12 = 48, 9 = 36, 6 = 24)
> 
> Letztlich ist "Airtime" ein schöner Wert dessen Aussagekraft jedoch
> Belanglos werden kann. :-)
> 
> 
> Dirk
> _______________________________________________
> 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   : end-[ping -s 50000] + -reply 189.JPG
Dateityp    : image/jpeg
Dateigröße  : 769856 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20071112/667acd3a/attachment.jpe>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : [ping -s 50000]+pckt-stat.png
Dateityp    : image/png
Dateigröße  : 73738 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20071112/667acd3a/attachment.png>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : klotz-zyklen.png
Dateityp    : image/png
Dateigröße  : 62126 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20071112/667acd3a/attachment-0001.png>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : µ-wave-oven 88.JPG
Dateityp    : image/jpeg
Dateigröße  : 420673 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20071112/667acd3a/attachment-0001.jpe>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : [ping -s 50000].JPG
Dateityp    : image/jpeg
Dateigröße  : 611593 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20071112/667acd3a/attachment-0002.jpe>