Forum: HF, Funk und Felder WLAN Verständnisfrage Stromverbrauch und Schlaf- und Wachzyklus


von Uwe R. (uwerothfeld)


Lesenswert?

Hallo zusammen,

ich habe mal eine Verständnisfrage zum Stromverbrauch einer WLAN 
Netzwerkkarte.

In einem Netzwerksimulator finde ich folgende Angaben für den 
Stromverbrauch einer WLAN-Karte:
1
**.wlan[*].sleepCurrent = 0.02mA
2
**.wlan[*].rxCurrent = 16.4mA
3
**.wlan[*].decodingCurrentDelta = 0mA
4
**.wlan[*].txCurrent = 17mA
5
**.wlan[*].setupRxCurrent = 8.2mA
6
**.wlan[*].setupTxCurrent = 8.2mA
7
**.wlan[*].rxTxCurrent = 17mA
8
**.wlan[*].txRxCurrent = 17mA
Wenn ich im Simulator einen Lauf starte, zeigt mir der Energieverbrauch 
keinen Zusammenhang zwischen der Anzahl von empfangen/gesendeten 
Nachrichten bzgl. des Energieverbrauchs. Daher vermute ich, dass die 
WLAN-Karte im Simulator nie in den sparsamen Schlafzustand wechselt und 
nur zwischen TX und RX wechselt, aber nie in den SLEEP Zustand geht.

Nun habe ich mal geschaut, finde aber keine Aussagen, wie es den in Echt 
ist (also z.B. beim Linux-Treiber). Wenn ich da mit einem WLAN-Netz 
verbunden bin, schläft die Netzwerkarte auch mal, oder ist sie wirklich 
immer im TX oder RX Modus??? Wäre cool, wenn jemand nen Link o.ä. hätte, 
wo man dies nachlesen kann, bzw. mir das erklären kann.

Schöne Pfingsten.

Gruß

uwe

: Bearbeitet durch User
von Hans Ulli K. (Gast)


Lesenswert?

Der Linux Treiber redet nur mir der Karte selber, ggf kann diese wenn 
vorhanden schlafen legen.

Davor ist aber noch cfg80211 api bzw. lib80211.
Die kümmern sich um Verschlüsselung, IE-Frames usw.

Der Sleep Mode geht auch nur mit dem AP zusammen wenn die Karte im STA 
Mode ist.
Der AP muss ja wissen, wann die Karte wieder aktiv ist.

Im Mode ist glaube ich auch kein Sleep definiert, da ja jederzeit ein 
AUTH/DEAUTH request machen sollte.

von Simon K. (simon) Benutzerseite


Lesenswert?

Was ist denn ein Netzwerksimulator?

von Uwe R. (uwerothfeld)


Lesenswert?

Hallo Hans,

danke für deine Antwort.

Also mein Netz (im Simulator) ist ein Infrastrukturnetz. Der 
SIM-WLAN-Treiber hat einen Reduzierten STA Stack, welcher aber definitiv 
Fehler hat (zum Beispiel beim WLAN-ACK).

Eigentlich wollte ich zeigen, dass durch eine Optimierung im zu 
testenden Protokoll die Lebenszeit verlängert werden kann, da die Anzahl 
der Sende- und Empfangsoperationen reduziert wurde. Also: Weniger Pakete 
zu übermitteln == Länger Akkuzeit. Dies kam aber nicht raus, da, so 
nehme ich an, die Karte nie schläft und Empfangen quasi genauso teuer 
ist wie Senden.

Ist meine ursprüngliche Idee schon quatsch, dass die Verringerung der zu 
senden und empfangenen Pakete die Lebenszeit erhöht?

Achso: Ein Netzwerksimulator ist so etwas wie NS2, NS3, bzw. (in meinem 
Fall Omnet++ http://omnetpp.org/intro (aktuell hat deren Seite wohl ein 
Problem ... ))

: Bearbeitet durch User
von Hans Ulli K. (Gast)


Lesenswert?

Uwe Rothfeld schrieb:
> Hallo Hans,

> Eigentlich wollte ich zeigen, dass durch eine Optimierung im zu
> testenden Protokoll die Lebenszeit verlängert werden kann, da die Anzahl
> der Sende- und Empfangsoperationen reduziert wurde. Also: Weniger Pakete
> zu übermitteln == Länger Akkuzeit. Dies kam aber nicht raus, da, so
> nehme ich an, die Karte nie schläft und Empfangen quasi genauso teuer
> ist wie Senden.
>

das geht soweit ich das Protokoll verstanden habe gar nicht.
Bin zwar nur in einem HAL Layer am arbeiten, aber da schaut man sich 
auch ein wenig den anderen Kram im Treiber an.
Senden ist immer teurer. es im Karten die haben einen externen 
Verstärker für den TX und RX Teil.

Hier wird mal ein wenig das PM erklärt
http://www.sss-mag.com/pdf/802_11tut.pdf
Das steht auch das der AP Buch führt

> Ist meine ursprüngliche Idee schon quatsch, dass die Verringerung der zu
> senden und empfangenen Pakete die Lebenszeit erhöht?

Ja.
Du kannst den Stromverbrauch nur wenig reduzieren.
Das hängt aber auch vom Treiber ab. Unter Linux scheren sich die 
Hersteller einen Dreck wegen PM (Powermanagement) soweit ich es lesen 
kann.
Teilweise wird PM aber auch aktiv abgeschaltet, weil die HW sch**ss* 
ist, bzw. zu aggressiv ist.
Kann aber auch die Software sein ...

Das kenne ich von meinen RTL8821AU Treiber (USB) surfen geht, wenn ich 
aber nur einen Radiostream höre bricht er nach einigen Sekunden ab.

> Achso: Ein Netzwerksimulator ist so etwas wie NS2, NS3, bzw. (in meinem
> Fall Omnet++ http://omnetpp.org/intro (aktuell hat deren Seite wohl ein
> Problem ... ))

von Uwe R. (uwerothfeld)


Lesenswert?

Hallo Hans,

also wenn ich hier in das Buch schaue:

A Field Guide to Wireless LANs: For Administrators and Power Users

https://books.google.de/books?id=GB-87qyhc8sC&pg=PA152&lpg=PA152&dq=WLAN+State+machine+STA&source=bl&ots=a6gCxtlZNT&sig=ZGY8VTAqrijqVi80Y2lqcbSK90Y&hl=de&sa=X&ei=rqBhVcOJEsaqsAGu9YDYBw&ved=0CBsQ6AEwAQ#v=onepage&q=sleep&f=false


steht da unter dem Abschnitt Power Management Details (Seite 186), dass 
eine WLAN Karte schon schlafen kann ( "doze" ), indem es dem AP dies 
mitteilt. Darauf muss die STA periodisch aufwachen und vom AP die 
zwischengespeicherten Pakete abholen.

Du meinst also, dass ist in den realen Treibern nicht drin bzw. 
ignoriert? Mh. Auch in deinen Link steht ja drin, dass das Device 
schlafen kann zum Power saving.

von Hans Ulli K. (Gast)


Lesenswert?

Uwe Rothfeld schrieb:
>
> Du meinst also, dass ist in den realen Treibern nicht drin bzw.
> ignoriert? Mh. Auch in deinen Link steht ja drin, dass das Device
> schlafen kann zum Power saving.

Das ist meine Vermutung ...

Aber um das zu entkräften ist es notwendig sich den Treiber selber 
anzusehen
Ein
git grep -A 5 CONFIG_PM drivers/net/wireless
gibt schon mal auf, ob PM aktiviert ist, ggf sind diese Funktionen auch 
auskommentiert !!

Hier mal ein Snippet vom ATH9K Treiber
1
static int ath_pci_suspend(struct device *device)
2
{
3
  struct pci_dev *pdev = to_pci_dev(device);
4
  struct ieee80211_hw *hw = pci_get_drvdata(pdev);
5
  struct ath_softc *sc = hw->priv;
6
  struct ath_common *common = ath9k_hw_common(sc->sc_ah);
7
8
  if (test_bit(ATH_OP_WOW_ENABLED, &common->op_flags)) {
9
    dev_info(&pdev->dev, "WOW is enabled, bypassing PCI suspend\n");
10
    return 0;
11
  }
12
13
  /* The device has to be moved to FULLSLEEP forcibly.
14
   * Otherwise the chip never moved to full sleep,
15
   * when no interface is up.
16
   */
17
  ath9k_stop_btcoex(sc);
18
  ath9k_hw_disable(sc->sc_ah);
19
  del_timer_sync(&sc->sleep_timer);
20
  ath9k_hw_setpower(sc->sc_ah, ATH9K_PM_FULL_SLEEP);
21
22
  return 0;
23
}
Hier wird die HW komplett (inkl Bluetooth) abgeschlatet

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.