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
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.
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 ... ))
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 ... ))
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