[Berlin-wireless] [technix] bit-raten wohnzimmer-automatik

Marco Tidow martidow
Mo Mär 19 17:54:13 CET 2007


On Sun, Mar.18. 12:23 +0100, dirk wrote:
> Hast du irgendwo etwas gefunden wie das Wifi-Gerät genauer die Auswahl
> trifft welche Modulation es letztlich einsetzt? Oder wird bei der Angabe
> <alle Datenraten> immer vom Bestmöglichen ausgegangen - aber wie wird
> dann herunter geregelt? Bis ein ACK (802.11) kommt? Über das
> Becon-Intervall werden AFAIK alle unterstützen Datenraten übertragen,
> aber eben nicht die mögliche für eine Verbindung.

leider nicht.  aber durch beobachtung der resultierenden transfer-rate
und arping/ping-response zeit lassen sich ein paar rückschlüsse auf diese
firmware/HAL-blackbox-interna ziehen.

schreibe mal aus dem gedächtnis, also bitte nicht schlagen.


aus dem in beacons/probe-responses (managed-master oder ad-hoc node) resp.
probe-requests(managed-client) von jedem device announce´ten rateset, d.h.
welche raten das jeweilige device beherrscht, kann ein nachbar herleiten,
welche raten/modulation zum jeweiligen gegenüber funktionieren können,
falls es die HF-bedingungen hergeben.

beacons/probes werden mit basic-rate versand, womit sichergestellt wird,
daß alle anderen teilnehmer diese info´s "verstehen", wichtig z.b. in mixed
b+g-mode netzen.  durch plumpe, mehrfache wiederholung von probe-responses
wird zudem packet-loss dieser info in der luft entgegengewirkt.


zudem existiert in der (per basic-rate versandten) wifi-preamble von unicasts
u.a. ein bit, daß signalisiert, ob der payload frame-part OFDM-moduliert ist.
darauf kann sich die de-modulation im receiver noch vorm eintreffen der
payload einstellen.  auf die konkrete bitrate der payload synchronisiert sich
der empfänger dynamisch selbst durch der payload vorangehende sync-bits ein.

(bei bestimmten madwifi/atheros-HAL kombinationen habe ich derzeit allerdings
 zweifel, ob die empfangs-modulations-wahl bei fest eingestellter _sende_-
 g-bit-rate _empfangs_-seitig trotzdem unabhängig passiert
 (bezogen auf dasselbe device!), u.a. bei foneras mit ff-adaption :
   die dinger werden taub für b-modulierte unicasts, wenn sie während
 laufender assoc von auto- auf fixe g-sende-rate umgestellt werden, hm?)


auch steht der firmware/HAL empfangs-seitig der signal-level zur verfügung;
indirekt, aus der AGC (autom.-gain-control) des receivers, die eine steuer-
spannung zur abschwächung des eingangs-signals aus der aktuellen
signal-amplitude des HF-carriers herleitet.

in g-mode fähigen devices kann ich mir einen threshold-mechanismus vorstellen,
der erst ab einem mindest receive-level überhaupt sende-seitige versuche mit
OFDM-modulationen und g-raten veranstaltet (oder die verbindung sonst sogar
einfach ignoriert?  s.u.).


über die reihenfolge probierter sende-raten kann ich auch nur spekulieren:

sende-seitig läuft´s dann auf den von Dir beschrieben try-and-error vorgang
hinaus, bit-rate solange runter, bis das ACK-packet von empfänger kommt.
(empfänger verschickt das ACK, wenn die FCS(frame-check-sum) des empfangenen
packets korrekt war).  dem entgegen findet eine langsame raten-steigerung
anhand der auswertung der bit-error rate (der umgekehrt vom empfänger retour
erhaltenen packets und ihrer empfangs-bit-rate) statt; so war´s jedenfalls
vor g-mode zeiten.


zusätzlich läuft parallel aber noch eine zweite heuristik, um auf schnelle
Änderungen der HF-bedingungen entsprechend reagieren zu können, und hier
wird´s ganz dunkel, von der doku her.

allein dürfte der ehrgeiz der hersteller und besonders das für ihre produkte
angepeilte einsatzfeld ein paar rückschlüsse hergeben:

  SoHo(small-office/home-office) Umgebung, mal ´ne küchen-mikrowelle,
  bluetooth-scheiß und, vor allem (!) andere wifi-netze in der luft, die
  man natürlich "aus-performen" muß...

  und leute, die rumlatschend dämpfen oder auch nicht, dreisterweise auch
  noch ihren wifi-kram surfend mitschleppen, dann autos, die rumparken,
  usw. ,  also "fading"-effekte wie man sie gern hat.

alles zusammen wohl dazu geeignet, zu vermuten, daß ein hersteller eine sehr
aggressive strategie einbaut, so oft und so schnell wie´s geht, immer wieder
schnellere bit-raten zu probieren, hauptsache, die google-seite geht auch
beim jogging um den wohnzimmer-tisch fix auf.  selbst wenn darunter der
gesamt-durchsatz desselben und aller anderen wifi-netze leidet, weil massen-
haft retries unterwegs sind.

und sie sind es tatsächlich,
dazu eine typische beoachtung:  wenn ein zwei(!)-node link sich automatisch
auf 36M-rate laut wl-util eingepeilt hat, kann man ihn auf z.B. 24M fix runter-
stellen und erhält trotzdem meistens so ziemlich dieselbe transfer-rate
aus dev-zero.
(in HF-ruhiger umgebung, aber tagsüber probiert!, nur nachts nach 04:00
 bringt die höhere rate wirklich markant mehr, bis ca. 06:00)


und der wohnzimmer-tisch ist total ernst:

trotz aller range-angaben zielen SoHo-devices auf sehr kleine netz-ausdehnung.
für WAN-links wollen die lieben herrschaften doch lieber teures profi-equipment
verscherbeln.  dann erscheint es nochmehr plausibel, daß der für hohe bit-rates
und OFDM-modulations notwendige HF-pegel in SoHo-devices für wahrscheinlicher,
also hohe raten als "probierenswerter" angenommen werden;   tatsächlich als
wesentlich geringer "gemessene" level (AGC) nur als das resultat kurzfristiger
störung betrachtet werden.  Eben, ohne eine art history/statistik dazu zu
führen und zur grundlage der raten-entscheidung zu machen :-(



wie lange eine einmal ermittelte, mit "erträglicher?" error-rate (BER)
funktionierde unicast-rate zu einem bekannten nachbarn von der wohnzimmer-
automatik beibehalten wird, ist IMO der entscheidende knackpunkt.

dazu folgende beobachtung:

die ping-zeiten über eine kette sich automatisch konfigurender olsr-nodes
wackeln um bis zu faktor 30, z.B. zwischen 10ms und 300ms, zwischen
einzelnen pings (std, 64 byte ICMP-packets).

stellte man alle nodes der kette fix auf die _langsame!_ rate 2M ein,
gingen die pings auf einmal mit 3 ms/hop (!!!), dieselbe node-kette lieferte
fast konstant antworten alle 10ms, typisch -1/+2 ms, über stunden.

seltene, einzelne ausreißer dauerten dann mal 30ms, so jedes zigte-packet.
wenn viel los war (z.B. auf "nachbar"-channels oder anderes wifi-zeug auf dem
eigenen), nahmen die ping-zeiten niveau-artig zu, aber moderat, blieben
typisch unter << 50ms, über die ganze kette (distanzen: 800m, 1600m, 40m).


offenbar spielt die rate-automatik unserer broadcoms ständig russisch-roulett,
auch während laufender transfers, selbst um den preis erheblicher packet-latenz,
wie es z.B. für audio-stream, VoIP ziemlich unbrauchbar ist.
vermutlich um so aggressiver, je "langsamer" die aktuelle rate grade ist, weil
solche ja wenig in das SoHo-bildchen passen, also nicht sein dürfen.




nochwas zur reihenfolge der probierten sende-raten

die in beacons announce´ten ratesets unterscheiden sich
zwischen broadcoms (binary-driver) und anderen g-devices.

(die in "Probe Response" genannten raten sollen, AFAIR, aufsteigend sortiert sein,
oder werden vllt. auch nur so von tools a la tcpdump, ethereal, wireshark
dargestellt)


aber laut "wl scan" ergeben sich für die in beacons gelisteten raten diese:

  broadcom (b-/g-mixed):

                           [ 1(b) 2(b) 5.5(b) 11(b) 18 24 36 54 6 9 12 48 ]

  dagegen bei atheros (non-madwifi):

                           [ 1(b) 2(b) 5.5(b) 11(b) 6 12 24 36 9 18 48 54 ]

  ein "Netgear" device dagegen wie die broadcom´s

                           [ 1(b) 2(b) 5.5(b) 11(b) 18 24 36 54 6 9 12 48 ]

  noch eine variante, einfach aufsteigend:

                           [ 1(b) 2(b) 5.5(b) 11(b) 6 9 12 18 24 36 48 54 ]


ob sich daraus schließen läßt, in welcher reihenfolge die kette broadcom-
binary-driver <-> broadcom-radio-firmware einzelne bit-raten probiert?

könnte(!) ein hinweis sein, daß die SoHo-automatik in broadcom´s zuerst
und laufend wieder hohe g-raten antestet.
würde passen (nur nicht zu freifunk).




interessant finde ich auch, daß unsere broadcoms in der default-config
"kaum" probieren, mit b-mode werten zu connecten, und/oder z.B. die tx-power
hinreichend hochzufahren, daß eine fernverbindung ggfs. doch zustande kommt.

selbst, wenn sie die beacons einer entfernten, auf b-raten fixierten und
auf fette tx-power manuell hochgestellten station empfangen, und der link
definitiv _gut_ funtkioniert, wenn beide seiten fix und manuell
auf b-rate + bißchen (aber zulässig!) mehr tx-power eingestellt sind:
  mit 0% packet-loss laut ping,
  bei realen transfers packet-loss < 5%, auch ohne RTS...

hier zeigt sich wohl die vorliebe der wifi-hersteller, lieber mehr AP´s (und
besonders solche neuerer generation) zu verticken ;-)




> Da nun wohl der Noise-Wert eher das Bitrauschen ist - dies steckt im
> PMD_SQ (?) Darüber könnte sich dann eine automatische Regelung für die
> Datenrate für die Verbindung ergeben, aber  wo findet letztlich die
> Kommunikation der Stationen darüber untereinander statt? In den Frames
> finden außer in dem Becon-Intervall keine weitere Information
> statt...allerdings ist das Becon ein Broadcast für alle Stationen...

AFAIK gibt es keine "negotiation" zwischen wifi-devices über die zu
verwendenden raten.  sie "schließen nur rück", was der andere zu können
behauptet und probieren dann(TX!, ACK?) bzw. sync-en sich ein (RX, hilfe).



> Anscheinend hatte CWN (ein Berliner WLAN-Provider?) sich dies wohl schon
> zu nutze gemacht (reduzierte Datenrate für bessere Übertragung) - gab es
> einen Austausch darüber wie Effektiv dies war (Papers) ?

ex-provider : RIP == "rest in peace"

CWN : city-wireless-networks

hatte nie kontakt zu denen; gab wohl mal talks über friedliche co-existenz
zwischen ff-vertretern und CWN in deren repräsentanz in der frankfurter-allee.
denke aber, über derartige geschäfts-interna werden sie sich wg. wettbewerbs-
vorteilen nicht ausgelassen haben.

oder?  jemand nichts genaueres?

tatsächlich gab´s zuletzt angesichts des nie stattgefundenen marketings
dieser herrschaften gerüchte, von wegen staatsnähe, schlapphut-fraktion,
test-balonx für watt auch immer, etc. pp.
jedenfalls sind´se wech und keiner weiß wer - was - wann - warum.

egal, weil:

mir ist bekannt, was aus scan´s und mac-layer monitoring sichtbar
wurde.  mittels eingeschränkter rateset-info hielten sie einerseits b-only
wifi-clients davon ab, mit ihren stations zu connecten, z.B. "[18(b)]"
(kurzeitig sah man auch mal "[18(b) 24 36]", was dann nach ein paar tagen
wieder auf die einzelne 18M rate zurück wechselte), und zum anderen sorgte
eine proprietäre, nicht 802.11-konforme modifikation der LLC-header fields
resp. entsprechende packets dafür, daß nur ihre kunden über CWN-links daten
austauschen konnten.
  das setzt zugriff auf firmware sources voraus, was für eine firma nicht
das problem darstellt, machte für mich weiteres nachforschen aber eben auch
uninteressant, weil solche leute per NDA geknebelt sind.


aber - channel-hoppen der anderen art:

in anderer hinsicht schienen sie mir weiter zu sein.  offenbar wechselten
ihre links automatisch den kanal, falls auf dem aktuellen zuviel los war.
da nach meinen infos auch auf kunden-seite extra CWN-devices postiert
waren, auch von daher kein problem.  was es gewesen wäre, so man übliche
wifi-hardware beim kunden zu versorgen gehabt hätte.

(N.b. ist angesichts 802.11s doppelt spannend, auch und grade für FF.
      alle die c´t 05/2007, S.208f gelesen?)

habe mit dem congestion-window gespielt, wenn CWN auf 9-11 unterwegs
waren, hat geholfen, meistens nach wenigen minuten ;-) .  so ganz an das
angeblich getroffene gentlemen-agreement, freifunk den 10er-Kanalbereich
zu überlassen, haben sich die figuren bei CWN zumindest zuletzt nicht
gehalten; seitdem hatte ich auch keine manschetten mehr, andere channels
für olsr-links z.B. auf der sama-church zu okkupieren.


Gruß, marco


_______________________________________________
Berlin mailing list
Berlin at olsrexperiment.de
https://www.olsrexperiment.de/cgi-bin/mailman/listinfo/berlin





Mehr Informationen über die Mailingliste Berlin