<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hallo Martin!<br>
      <br>
      Am 2012-09-07 00:49, schrieb Martin Asmus:<br>
    </div>
    <blockquote
      cite="mid:bfa0980d-96a5-4f85-9f79-2778ae9e68b0@email.android.com"
      type="cite">
      <p>Hallo,</p>
      <p>ich hätte da mal eine allgemeine (eher theoretische) Frage:<br>
        Bei den letzten Testtagen habe ich gelernt, dass bestimmte
        bitraten an gewisse 802.11-Standards gebunden sind. (Zusätzlich
        zu den  Bereichen, die sich durch die Obergrenzen der Standards
        ergeben)<br>
      </p>
    </blockquote>
    Du sprichst von der Bruttodatenrate, wie ich annehme.<br>
    <blockquote
      cite="mid:bfa0980d-96a5-4f85-9f79-2778ae9e68b0@email.android.com"
      type="cite">
      <p>
        Konkret die (in der markit-firmware auch als (b)
        gekennzeichneten) Bitraten 1, 2, 5.5, und 11, bei denen nach
        b-Standard kommuniziert wird, unabhängig davon, was sonst
        konfiguriert wurde.<br>
      </p>
    </blockquote>
    <br>
    Die Markit-Firmware kenne ich nicht so gut, aber es gibt
    Unterschiede im Funktionsumfang von iw, iwconfig, ... gegenüber den
    "neueren" Firmwares.<br>
    Da kann man gewisse Einstellungen nicht vornehmen, da sie dem
    Rate-Algorithmus vorbehalten sind.<br>
    Für 802.11b/g (also 2.4Ghz) stimmt das. G erweitert B um neue
    Modulationsverfahren, die man bei unseren Firmwares aber nur über
    Hostapd setzen kann, der im Adhoc-Mode gerade nicht verwendet wird.
    Somit ist der gemeinsame Nenner stets DSSS/CCCK mit den obgenannten
    Raten.<br>
    Im B-Modus besteht aber das Problem, dass das Gerät mit der
    geringsten Datenrate die Datenrate für alle verbundenen Stationen
    vorgibt. Dieses Problem wurde im G-Modus mit dem sogenannten
    protected-G-Modus eliminiert, sodass g-Geräte von b-Geräten nicht
    ausgebremst werden. Ob dieser aktiv ist, konnte ich nicht
    feststellen, vermute allerdings, dass dies aufgrund der Natur von
    AdHoc nicht der Fall ist - siehe unten.<br>
    <blockquote
      cite="mid:bfa0980d-96a5-4f85-9f79-2778ae9e68b0@email.android.com"
      type="cite">
      <p>
        Hab ich das soweit richtig verstanden?<br>
      </p>
    </blockquote>
    Die Konfiguration trifft im AdHod-Mode nicht zu und ist daher
    irrelevant, siehe unten.<br>
    <blockquote
      cite="mid:bfa0980d-96a5-4f85-9f79-2778ae9e68b0@email.android.com"
      type="cite">
      <p>
        Nun hab ich entdeckt, dass mein Router gerade mit 11Mbit rx und
        54 Mbit tx verbunden ist. Bedeutet, dass jetzt, dass er für den
        Empfang b verwendet, und für's Senden was auch immer eingestellt
        ist?</p>
    </blockquote>
    Da spielen mehrere Faktoren mit, und es muss nach Szenario
    unterschieden werden, da bei den Atheros-Geräten, die Minstrel
    verwenden ein anderes Verhalten als bei den Broadcom-Chipsätzen
    beobachtet wurde:<br>
    <br>
    a) AdHoc: Datenraten sind (waren?) für AdHoc nur bis 11 Mbit
    spezifiziert. Alles darüber ist
    "[chip-/treiber]herstellerspezifisch" (laut diversen Quellen im
    Netz).<br>
    b) Die Einstellung des Modus b/g/n funktioniert (unter Backfire)
    nicht mit AdHoc, sondern nur mit dem Master/ClientMode (andere nicht
    getestet). Man kann die Änderung zwar angeben, der in mac80211.sh
    (in /lib/wireless) ausführende iw-Befehl kann dies jedoch gar nicht
    setzen (Ath9k). Im Master-/Clientmode tun dies Hostapd (hostapd.sh)
    respektive der Supplicant (wpasupplicant.sh) und zwar jeweils pro
    konfigurierter SSID.<br>
    In aktuellen Builds darf man anscheinend nicht einmal mehr den
    channel global setzen, weil "wifi" sonst eine Fehlermeldung ausgibt.
    (Umrechnungsproblem channel/frequency? Bug?)<br>
    c) Multicastraten bestimmen unter Atheros lediglich die
    Maximaldatenrate in Senderichtung (nachprüfen!), während andere
    Signale durchaus verarbeitet werden. Man kann also durchaus auch
    höhere Raten empfangen. Ohne gesetzte MC-Rate oder bei
    Verhandlungsproblemen scheint ein Fallbackmechanismus zu greifen,
    der von der geringst möglichen Rate ausgeht und dann je nach Gerät
    und Signalqualität zu verhandeln versucht, was bei "n"-Geräten
    untereinandere anscheinend sehr gut funktioniert, im der Kombination
    mit b/g-Geräten fallweise versagt. (Da hilft die MC-Rate). Die Rate
    zu setzen, macht die 802.11b/g-Geräte (Broadcom) allerdings
    unempfindlich für Clients mit höheren MC-Raten (sie werden
    anscheinend ignoriert).<br>
    d) Möglicherweise gibt es auch eine "Stromsparfunktion" bei Ath9k,
    die, wenn keine Daten übertragen werden eine geringere Rate in
    Senderichtung einstellt. - Das ist eine Vermutung, für ein
    Verhalten, das wir auf den Testtagen beobachtet haben.<br>
    <br>
    In deinem Fall vermute ich, dass Du auf der Markit-Firmware die
    MC-Rate und Datenrate auf "Auto" belassen hast, während dies beim
    Linkpartner nicht der Fall ist.<br>
    <br>
    More Info please!<br>
    <br>
    <blockquote
      cite="mid:bfa0980d-96a5-4f85-9f79-2778ae9e68b0@email.android.com"
      type="cite">
      <p>LG<br>
        Martin</p>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
    </blockquote>
    <br>
    LG<br>
    Erich<br>
  </body>
</html>