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

[bruno randolf]

hallo!

mir faellt auf, dass euer [horst] output immer monochrom ist. probiert mal 

TERM=xterm-color horst -i mon0

dann sollte der auch in farbe sein. sollte eigentlich auch am wrt klappen, 
aber ich hab noch keinen zum testen...

On Tuesday 13 November 2007 06:42:37 Horst Krause wrote:
> 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

hmm, nicht ganz.
wir gehen davon aus, dass das rohr theoretisch immer 54Mbit gross ist.

phy rate sagt im prinzip aus wie DICK die pakete (oder ratten???) sind die 
durch das rohr gehen. je groesser die PHY rate je DUENNER die pakete, dh. 
umso mehr ratten koennen gleichzeitg durch das rohr laufen. [ja, is ne doofe 
analogie... aber mir faellt grad nix besseres ein ;)]

und die PHY RATE wird pro paket eingestellt, dh, du kannst ein dickes paket 
haben und dann ein duennes, etc... im grunde gehts bei der ganzen airtime 
geschichte darum das zu zeigen: wenn die pakte duenner sind (z.b. 54M) dann 
passen mehr durchs rohr, und wenn ne dicke ratte das rohr blockiert passen 
insgesamt weniger durch.

>  USAGE sagt, wie voll das 'rohr' insgesamt ist; und

jep.

>  AIR-TIME%, welchen anteil davon einzelne paket-typen haben.

genau!

> 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.

die usage ist momentan auf 54Mbit/sec eingestellt, ein wert, den du auch 
theoretisch bei voller auslastung nicht erreichen kannst, wie in der 
diskussion erwaehnt wurde (ich schaff hier bei maximalem traffic so um die 
70% usage%). das muss noch getuned werden. und mit nem ping schaffst dus 
sowieso nicht annaehernd deinen link auszulasten, da musst du schon mehr 
ratten durch rohr jagen...

> -------------------------------------------------------------------
> 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.
> ------------------------------------------------------------------- 

mach dir keinen kopf wegen RX und TX - auf der ebene auf der wir uns bewegen 
ist das exclusiv, dh. waehrend du TX, kann ich nur das was du sendest RXen. 
wenn du selbst sendest sollte dein treiber das dem monitor interface auch 
sagen, dh du siehst deine eigenen pakete (das ist zumindest im madwifi so, wo 
di monitor und normale interfaces parallel haben kannst.) andere karten 
koennen sowieso nix senden wenn du im monitor mode bist.

die usage% und die bps werden im sekundentakt ermittelt, das sollte als 
beobachtungszeitraum reichen. und 100ms sind wirklich schnell vorbei, dh 
sollten wir 100ms mal was unrepraesentatives zeigen, hab ich damit auch kein 
problem :)

bruno

>
> 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