[Berlin-wireless] Datenübertragungsratenfoo

[Sven-Ola Tuecke]

Hallo Harald,

vergiss die einfache Datenrate, die von irgendwelchen Tools ausgegeben
wird. So läuft das nicht. Hier ein paar Punkte zur Beachtung:

  * Technisch unterschieden wird zunächst mal zwischen
    Broad/Multicast-Rate (gilt für alle Nachbarn, meistens festgelegt)
    und der Unicast-Rate (gilt für jeden Nachbarn einzeln, meistens
    ausgehandelt, Stichwort "Rate-Control-Algo").
  * Die Unicast-Datenrate wird immer, möglicherweise auch die
    Sendestärke, und vielleicht sogar noch die ACK-Time ("Entfernung")
    in einer Nachbar-Tabelle verwaltet. Diese Nachbartabell kann noch
    diverses anderes enthalten z.B. Stromspar-Handling (PSPOLL usw). Die
    ist jedenfalls häufig implementationsabhängig bzw. davon, was die
    Hardware und der Treiber können bzw. richtig machen.
  * Also wenn schon Unicast-Datenrate, dann immer bezogen auf die
    MAC-Addi des jeweiligen Nachbarn.
  * Bei HardMAC ("MAC-handling auf dem Chip") ist so eine
    Nachbar-Tabelle ist häufig nicht sehr groß (8-64 sind bekannte
    Werte). Meist von Firmware realisiert. Häufig Buggy. In jedem Fall
    undurchsichtig. Und zeitkritisch. Bei SoftMAC aka
    Mac80211-Kernel-Modul ("MAC-Handling in Software realisiert") sieht
    das meist besser aus.
  * Die Datenrate kann z.B. bei aufeinanderfolgenden Frames variieren.
    Beispielsweise könnte ein Datenpaket mit 54Mbit gesendet werden, das
    nächste "ACK" dann nur mit 38Mbit. Das ACK langsamer, weil die paar
    Bits eines ACK-Frames bei 36, 48, 54 Mbit in ein OFDM-Symbol passen.
    Da 36 Mbit zuverlässiger sind...
  * Apropos OFDM-Symbol. Wifi arbeitet mit "nur" 250.000 Symbolen pro
    Sekunde. Die unterschiedliche Datenrate ergibt sich aus "wieviel Bit
    werden zu einem Symbol zusammengefasst". Und ggf (bei Mimo) wieviel
    Streams können zusammengefasst noch mehr Bits pro Symbol übertragen.
    Als Randnotiz: es gab / gibt wohl auch 0.25 Mbit und 0.5 Mbit
    Übertragungsraten. Spezialkram - nutzt wohl niemand mehr.
  * Die Datenrate kann asymmetrisch sein: eine Station sendet mit 1Mbit,
    die Nachbarstation sendet mit 24 Mbit. Die Datenrate kann innerhalb
    eines Frames nicht wechseln.
  * Wenn ein langsamer Client die Datenrate für alle anderen Teilnehmer
    'runterzieht, dann sieht das eher nach einem Treiberfehler aus. Die
    gibts - sollte aber ned sein ;-)

Gruß // Sven-Ola

Am 10.01.2015 um 20:02 schrieb Harald Stürzebecher:
>
>
> Am 10.01.2015 17:52 schrieb "Bastian" <fly at d00m.org
> <mailto:fly at d00m.org>>:
> >
> > Hallo Harald,
> >
> > sind die 1-2 MBit/s vor Ort gemessene Werte? Ins Internet oder mit eidem
> > Benchmark-Wget aus der Status-Seite vom AP?
>
> Das war eine Betrachtung der Monitoringdaten.
>
> > Die WLAN-Bitrate Werte von iwinfo sind nicht so richtig repräsentativ
> > wenn gerade keine Bandbreite erzeugt wird. Ein Idle-Client ist AFAIK
> > immer mit 1 MBit/s TX/RX assoziiert. Stromsparen und so...
>
> Das wäre möglich. Wenn dann auch noch die Sendeleistung reduziert
> wird, würde das die -90dBm Signalpegel genauso erklären, wie ein weit
> entfernter Client mit schlechter Verbindung.
>
> Vielleicht haben die Nutzer im Moment weniger Bedarf. Im Dezember
> wurden bis zu 10 GB/Tag heruntergeladen, jetzt sind es nur noch 2 GB/Tag.
>
> Ich werde das einfach mal weiter beobachten und nicht gleich nach
> einem Problem suchen, wo keines ist.
>
> Harald
>
>
>
> _______________________________________________
> Berlin mailing list
> Berlin at berlin.freifunk.net
> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20150110/15837953/attachment.html>
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 181 bytes
Beschreibung: OpenPGP digital signature
URL         : <http://lists.berlin.freifunk.net/pipermail/berlin/attachments/20150110/15837953/attachment.pgp>