WLAN: Auswirkungen von Beacon Interval + DTIM auf StandBy-Zeit

M

mittelhessen

Enthusiast
348
Wer sich schon mal näher mit WLAN-Parametern beschäftigt hat, dem sind sicher die Parameter Beacon Interval und DTIM aufgefallen.

Eine englischsprachige, aber gute (aufführliche und verständliche) Beschreibung gibts auf den Hilfe-Seiten der DD-WRT Firmware. Die beiden Parameter lassen sich aber auch bei jedem besseren WLAN-Router/Access-Point einstellen.

Beacon Interval

DTIM (Delivery Traffic Indication Message)

Nun habe ich mal mit meinem Linksys WRT54GL und meinem Galaxy Nexus (Andoid 4.2.1) mit den beiden Parametern etwas experimentiert.

Als Grundlage habe ich DTIM erstmal auf 1 belassen um zu schauen, bis zu welchem Beacon Interval die Verbindung zwischen Router und Handy im StandBy überhaupt stabil bleibt.

Heraus kam ein max. Beacon Interval von 500 ms!

Bei Werten > 500 ms kamen z. B. eingehende E-Mails (ich nutze Push!) erst dann an, wenn ich das Handy aus dem StandBy geholt habe. Bei sehr hohen werden (z. B. 1000 ms) war dann sogar das WLAN-Symbol zunächst grau, wenn ich das Handy aus dem StandBy geholt habe.

Da mit 500 ms als Beacon Interval jedoch zu lang sind (ich nutze WDS und möchte zwischen den beiden Routern einen sauberen und zuverlässigen Handover), bin ich auf 50 ms herunter und habe gleichzeitig DTIM auf den Faktor 10 gesetzt. In Summe kommt das Galaxy Nexus damit im StandBy auch auf ein Intervall von 500 ms!

Soweit so gut!

Nun habe ich aber erkannt, dass ich bei kürzeren Bakenintervallen mit DTIM deutlich höher gehen kann als es die Rechnung vermuten lässt.

D. h. Bei einem Beacon Intervall von 50 ms ist bei mir ein DTIM von bis zu 25 möglich und die Verbindung läuft trotzdem noch stabil!

Warum ist das so?
 
Nach über einem Jahr hat noch keiner eine Erklärung dafür? Ich habs bisher leider selber auch nicht herausgefunden. Was ich nur inzwischen weiß: es hängt auch vom Client ab.
 
Nun ich denke, deine Anforderung ist etwas zu speziell :)
Ich kenne einige hauptberufliche Netzwerktechniker, wenn es ums Wlan geht, schauen aber alle, dass die Land gewinnen.
Ich denke mal, dass sowas meistens in Bastlerei endet und es keine Tabellen gibt, welche Werte zwischen welche Hardwaregeräte funktionieren. Vielleicht hängt sowas auch von der Reichweite und Reflexionen ab die gerade herrschen.
 
Sorry wenn ich das so in den Raum werfe, aber ich versteh den Sinn nicht :o :p
 
Naja, je weniger Beacons und je länger der DTIM Intervall ist, desto weniger Strom brauchts.
Ich denke, dass das die Idee vom TE ist.
 
Da liegt doch dann aber der Hase im Pfeffer begraben :p Weil soweit ich das verstanden, ist doch alles auf Automatik eingestellt :) Will man das manuell einstellen, geht das doch nur für 1 Gerät, oder hab ich da grad n Denkfehler? Denn nicht jedes Gerät funktioniert ja gleich :)
 
Für das Beacon Interval und DTIM gibt es keine Automatik, weil man ja keine dynamische Anpassung braucht. Diese beiden Parameter werden fest im Access-Point eingestellt. Es mag Router geben, bei denen diese Parameter nicht einstellbar sind, aber auch diese haben natürlich Werte für diese Parameter. Devzero hat es schon gut erkannt! Gerade DTIM dient ja der Energieeinsparung, aber es ist eben ein Faktor für das Beacon Intervall, weshalb diese beiden Parameter immer zusammen betrachtet werden müssen. Beim Ausprobieren ist mir aufgefallen, dass unterschiedliche Clients im StandBy bei zu hohen Werten der beiden Parametern die Verbindung verlieren. Wie hoch man gehen kann, hängt tatsächlich vom Client ab, so dass man die Parameter als Worst-Case an den "schlechtesten" Client anpassen sollte.
 
Cool :) Wieder was gelernt (man kann ja nicht alles wissen :p ) :)

Weil du meintest, es mag Router die dynamisch arbeiten ;) Als Beispiel sei da mal die FritzBox genannt. Dort kann ich derartige Einstellungen bspw nicht vornehmen. Ich kann das WLAN Signal in der Stärke senken, aber das wars :)

Aber echt interessant wenn man so das 1 oder andere Watt einsparen könnte :)
 
Otandis_Isunos schrieb:
Weil du meintest, es mag Router die dynamisch arbeiten ;)

Wie oder was soll ich gemeint haben? Das verstehe ich jetzt nicht.

Otandis_Isunos schrieb:
Als Beispiel sei da mal die FritzBox genannt. Dort kann ich derartige Einstellungen bspw nicht vornehmen. Ich kann das WLAN Signal in der Stärke senken, aber das wars :)

Diese feinen Einstellmöglichkeiten, beziehen sich in erster Linie auf alternative Firmwares (z. B. DD-WRT, Bitswitcher, ...). Consumer-Geräte bieten diese Einstellmöglichkeiten i. d. R. ab Werk nicht, weil der Normalverbraucher damit sicher eher überfordert wäre.

Otandis_Isunos schrieb:
Aber echt interessant wenn man so das 1 oder andere Watt einsparen könnte :)

Die Einsparung liegt sicher nicht im Watt-Bereich und liegt ja auch auf Seiten der Clients und nicht auf der Seite des Access-Points. So wie ich es aktuell einschätze, lässt sich da aber nur beim Multicast-Empfang (also während der Client aktiv ist und Multicast (z. B. Radiostreams) empfängt) Energie sparen.

Im StandBy spielt zumindest DTIM wohl keine Rolle, wenn ichs richtig verstehe. Oder doch???
 
Den Link hatte ich ja oben bereits gepostet! ;-) Aber das Beacon Intervall könnte doch auch im StandBy durchaus ausschlaggebend für den Energieverbrauch der Clients sein, oder?
 
Ja, ich weiß :)

Wollt den dennoch nochmal mitsenden, einfach nur weils geht :D

Hmm, im Standby werden aber keine Daten übertragen, deswegen ist ja DTIM im Standby nutzlos. Vereinfacht gesagt, wenn ich das jetzt richtig interpretiert habe, gibt der DTIM ja nur an, in welchem Zeitabstand ein gepuffertes Broad-/Multicastpaket gesendet werden soll :o

Argh ist der Kram kompliziert :D Und wenn keine Daten übertragen werden, schläft ja die WLAN-Karte sozusagen. Um dann richtig Energie zu sparen hilft es eigentlich nur, den Clienten direkt zu trennen. Entweder durch eine bestimmte Zeitspanne, oder aber, wenns um einen Androiden geht, wenn bspw der Bildschirm ausgeht :)
 
Wie siehts denn aus, wenn das Handy mit verbundenem WLAN im StandBy-Modus ist und keine Daten übertragen werden? Zumindest der WLAN-Empfänger des Handys muss doch regelmäßig aktiviert werden, um zu schauen, ob die Verbindung noch da ist (respektive andere Verbindungen) oder Daten empfangen werden sollen. Vermutlich ist das der Kernel Wakelock wlan_rx_wake, der sich ohne anderen Kernel wohl kaum reduzieren lässt. Aber wäre ein kurzes Broadcast Intervall da günstig oder eher nicht?

Da ein kurzes Beacon Intervall für eine eher stabile Verbindung sorgt, kann ich mir vorstellen, dass dies den Verbrauch eher begünstigt. Eine Beacon kommt beim Client ja eher an wenn dieser mal aufwacht.

EDIT: So wie man hier lesen kann, ist wohl eher ein längeres Beacon Interval günstiger für einen geringen Energieverbrauch, da sich die Clients wohl mit ihrem "Hören" an das längere Beacon Interval "anpassen":

Communications in a wireless LAN are centered on the AP. Because APs are
stationary, the distance a beacon frame can travel reliably does not vary over
time. Stations monitor the beacon frames to determine which Extended Service
Sets (ESSs) provide coverage in their area. They also use the received signal
strength to monitor signal quality.
An increase in the beacon interval increases the power-saving capacity of
attached nodes, because it alters the listen interval and the delivery traffic
indication message (DTIM) interval.
A larger interval can increase throughput
by decreasing contention for the signal. That is, the time spent to send beacon
frames can instead be used to transmit data.
A decrease in the beacon period makes passive scanning more reliable and speedy
because the network is more frequently announced to the radio. Further, a smaller
beacon interval makes mobility more effective because it increases the coverage
information available to nodes. Because of this, nodes that move around rapidly
can benefit from these beacon frames because they update signal strength information.
DTIM tells power-saving stations that a packet waits for them. The DTIM period
indicates how many beacon frames can transmit before another DTIM is transmitted.
An increase in the DTIM period count allows clients to sleep longer; however, it
delays the delivery of multicast and unicast packets.
Because the packets are
buffered, large DTIM period counts can cause a buffer overflow.

Bei der Beschreibung für DTIM hat sich dort meiner Meinung nach ein kleiner aber feiner Fehler eingeschlichen. Ich vermute, dass es "multicast and broadcast" und nicht "multicast und unicast" heissen müsste. So stehts auch in der DD-WRT Beschreibung und so macht es auch Sinn.
 
Zuletzt bearbeitet:
So, heute Vormittag hab ichs noch mal den Einfluss des Beacon Intervals auf den wlan_rx_wake getestet. DTIM habe ich auf 1 gestellt, während ich drei verschiedene Bakenintervalle (10 ms, 200 ms, 500 ms) mehrmals für jeweils ca. 5 Minuten getestet habe. In dieser (kurzen!) Messzeit läuft der wlan_rx_wake zu ca. 7-12 % der StandBy-Zeit (verhindert also genauso lange den Deep Sleep). Aus Erfahrung weiß ich, dass der wlan_rx_wake eher stark zurück geht, sobald das Handy längere Zeit im StandBy-Modus ist. Deshalb erreiche ich auch Deep Sleep Zeiten von > 95 %. Die wichtigste Erkenntnis ist aber, dass es für den wlan_rx_wake scheinbar überhaupt keine Rolle spielt, ob das Bakenintervall 20, 200 oder 500 ms lang ist. Da Clients im StandBy-Modus aber gerne mal die Verbindung verlieren, wenn das Bakenintervall zu lang ist (beim iPhone sind wohl die standardmäßigen 100 ms schon machmal problematisch), belasse ich das Bakenintervall auf den 50 ms.
 
Ich denke mal, um das Optimum rausholen zu können, bedarf es auch eine Anpassung der einzelnen Clienten. Allerdings wäre mir jetzt nicht bekannt, wie man einen WAKE_UP auf einen niedrigeren Wert setzen KÖNNTE, so das das Gerät vllt doch noch etwas länger im DeepSleep ist.

Evtl ist das sogar garnicht möglich, wer weiß :)
 
Mit root kann man wohl ein anderes (höheres) Listen-Interval fürs passiv-Scanning im Android-Client einstellen. Mangels root ist das für mich aber keine Option. Deshalb versuche ich das über den Access-Point zu optimieren, was aber scheinbar nichts bringt.
 
Hallo Leute! / speziell @mittelhessen und @Otandis

Ich weiss, dass es nicht ganz hier gehört, aber ich sehe, ihr seid in der Thema WLAN wirklich erfahren. Ich suche solche Leute hier sozusagen. :thumbsup:
Könnt ihr mal mir (und eventuell damit anderen) ein bisschen weiterhelfen eine Lösung zu finden?

Ja und noch was. Wo ich erstmals gepostet habe, konnte damit niemand etwas anfangen. Sollte ich wo anders erneut posten oder verschieben lassen?

https://www.android-hilfe.de/forum/...achrichten-verspaetung-ueber-wlan.615081.html

Danke im Voraus!
 
Naja, erfahren triffts eher nicht, da man das Thema nicht vollständig verstehen kann, ohne sich intensiv damit zu beschäftigen :/ Es ist wie immer ein sehr kompliziertes Thema.

Auf der anderen Seite ging es hier eigentlich darum den Energiebedarf zu senken und das WLAN nicht so einzustellen, dass Push sozusagen "Daueraktiv" ist. Normalerweise ist das ja der Fall. Bsp Hangouts (früher Google Talk), da funktioniert bei mir der Push einwandfrei, egal wielange mein Gerät im Standby liegt oder nicht und Hangouts nutzt ja Google Cloud Messaging.

Von daher könnte es tatsächlich, wie schon im anderen Thread angesprochen, an der Android-Version liegen. Es sind aber immer wieder nur Ratespiele. Zumal eine Anpassung der einzelnen Geräte immer schwierig ist, da man erstmal wissen muss, wo man direkt ansetzen muss. Beim WLAN-Treiber? Im Networkmanager (falls es sowas bei Android gibt?)?

Schwierig, wirklich.
 
Wenn dein Smartphone im WLAN jederzeit anpingbar ist, dann liegt das nicht an einer eingeschlafenen bzw. abgebrochenen WLAN-Verbindung. Dass die ersten Pingantworten teilweise länger (bis hin zu wenigen Sekunden) dauern können, ist wohl dem Energiesparmodus zu verdanken. So wie ich das einschätzen kann, ist das normal und war auch bisher bei allen von mir verwendeten Handys so. Da dein Problem demnach, so wie ich das sehe, nichts mit dem Beacon-Interval und DTIM zu tun hat, habe ich dir in dem von dir verlinkten Thread geantwortet. Um das Beacon-Interval und DTIM gänzlich auszuschließen, würde ich für die Testphase das Beacon-Intervall auf den üblichen 100 ms belassen (oder kürzer) und das DTIM auf 1 (also quasi abschalten).
 
Otandis_Isunos schrieb:
...

Von daher könnte es tatsächlich, wie schon im anderen Thread angesprochen, an der Android-Version liegen. Es sind aber immer wieder nur Ratespiele. Zumal eine Anpassung der einzelnen Geräte immer schwierig ist, da man erstmal wissen muss, wo man direkt ansetzen muss. Beim WLAN-Treiber? Im Networkmanager (falls es sowas bei Android gibt?)?

Schwierig, wirklich.

Danke für die schnelle Antwort. Ich habe verstanden worum bei Beacon and (D)TIM geht. Wollte nicht das Thema wechseln natürlich.
Habe nur gesehen dass ihr davon etwas wirklich versteht. Da kam ein bisschen Hoffnung, dass ihr vielleicht bei meinem Problem auch helfen könnt. :winki:
 

Ähnliche Themen

W
Antworten
4
Aufrufe
2.116
Klaus986
K
1
Antworten
2
Aufrufe
162
maik005
maik005
K
Antworten
7
Aufrufe
162
MvBoe
MvBoe
Zurück
Oben Unten