Der Akku-Thread zum Samsung Galaxy S3: Akkulaufzeiten, -Probleme und mehr

[Odi123]

Also ich habe mal über Nacht getestet. Alle Apps, die ich normalerweise verwende, waren offen. Mobiles Internet und Wlan waren an. Ich denke, ich kann zufrieden sein. Aber ich glaube dieser Test repräsentiert nicht die Realität. Wenn ich unterwegs bin, zieht es viel mehr Akku. Aber vllt täusch ich mich auch ein wenig, weil ich unterwegs mehr rumspiele und das Display ist ja der größte Akkufresser beim S3.

hast du die bildschirmhelligkeit auf auto gestellt? unterwegs wird nicht das display der größte fresser sein sondern umts. bei custom kernels hat man das problem nicht da er besser die umts profile nimmt. vorallem die idle profile. es gibt dafür auch ein begriff aber mir fällt der gerade nicht ein, vll. weiß ja einer wie das heisst womit man das besser einstellen kann. gibt auch einige threads hier deswegen.

lg

 

[vAmP_irE]

Hier der Log von heute Nacht.

WLAN off mobile Daten on:

http://db.tt/D51a5VJY

Kein Vergleich zu WLAN on. Liegt das am WLAN Router der Verbrauch

 

[Effe101]

Servus, kann es sein dass GoogleMaps meinen Akku leer saugt.
Bin immer mit einer Akkufüllung sehr gut über den Tag gekommen, seit ca. ner Woche muss ich abends schon wieder Laden.
Also mal bei BetterBatteryStats nachgesehen, dort habe ich jetzt nach 10h Laufzeit, 7h Deep Sleep, 3,5h Awake und 2h Screen on bei "Alarms" 1100 Wakeups von com.google.android.apps.maps

Ist das Normal? Bisher hatten so hohe Wakeups bei mir nur Facebook und Ebay.

 

[Rob2222]

Also ich habe mal über Nacht getestet. Alle Apps, die ich normalerweise verwende, waren offen. Mobiles Internet und Wlan waren an. Ich denke, ich kann zufrieden sein. Aber ich glaube dieser Test repräsentiert nicht die Realität. Wenn ich unterwegs bin, zieht es viel mehr Akku. Aber vllt täusch ich mich auch ein wenig, weil ich unterwegs mehr rumspiele und das Display ist ja der größte Akkufresser beim S3.

Ja, die Werte sind TOP.
Das ist bei Dir die ganz normale Nutzung, weswegen sich Dein Akku leert.
=> Alles normal.

Gruß
Rob

Der ursprüngliche Beitrag von 11:31 Uhr wurde um 11:33 Uhr ergänzt:

Hier der Log von heute Nacht.
WLAN off mobile Daten on:
http://db.tt/D51a5VJY
Kein Vergleich zu WLAN on. Liegt das am WLAN Router der Verbrauch

Ja, dieser Dump ist super. 0.9%/h mit Mobilem Internet und 95% Deep Sleep. Super.

Mach mal ein Dump über Nacht so wie diesen, bei dem Du das Handy nicht nutzt, auf WLAN zum Vergleich.

Gruß
Rob

Der ursprüngliche Beitrag von 11:33 Uhr wurde um 11:35 Uhr ergänzt:

Servus, kann es sein dass GoogleMaps meinen Akku leer saugt.
Bin immer mit einer Akkufüllung sehr gut über den Tag gekommen, seit ca. ner Woche muss ich abends schon wieder Laden.
Also mal bei BetterBatteryStats nachgesehen, dort habe ich jetzt nach 10h Laufzeit, 7h Deep Sleep, 3,5h Awake und 2h Screen on bei "Alarms" 1100 Wakeups von com.google.android.apps.maps
Ist das Normal? Bisher hatten so hohe Wakeups bei mir nur Facebook und Ebay.

Huhu,
wenn Du das Handy mal über Nacht liegen lässt und ein BBS Dump machst und hier anhängst, könnte man das genauer sagen.

Ja, Maps kann durchaus die Ursache sein. Du könntest in den Maps bzw. Android Standorteinstellungen die ganzen Dienste abschalten, dann würde Maps weniger Akku verbrauchen.

 

[Cy4n1d3]

Mahlzeit

Maps bzw. Latitude hat bei mir auch etliche Wachzeiten verursacht, in den Maps Einstellungen am Besten alles ausmachen was nach Standort aussieht und evtl. sogar in den Systemeinstellungen Standortdienste deaktivieren.
Dann ist da auf jeden Fall Ruhe... scheint sich aber auch irgendwie um einen Fehler zu handeln, früher waren die Waketimes viel geringer.

Siehe beispielsweise: Issue 34458 - android - Google Maps wakelock issue - Android - An Open Handset Alliance Project - Google Project Hosting


@Rob:
Ich habe gestern mit GetRIL gespielt und mir ein passendes Modem geflasht, die RIL war DLI2/DLI3, Modem DLIB. Da es keine RIL für DLIB gab habe ich daher das DLI3 Modem geflasht - wie man am Log sieht hat das leider nicht geholfen. Mal sehen, vielleicht findet sich ja irgendwo im Netz mehr zu diesen ominösen Paketen.

LG

 

[Rob2222]

Huhu,

so, jetzt mal zu den WLAN Problemen. Ich habe mich die Tage etwas mit dem Problem "unsauberes" WLAN welches das S3 aufweckt befasst. Dazu habe ich mit der App "Shark for Root" die WLAN-Pakete mitgeschnitten und am PC mit dem Programm Wireshark bzw. einfach online auf der Webseite cloudshark.org ausgewertet.
Hier jetzt mal eine kleine Zusammenfassung für alle, die es interessiert:


Einschub: Wieso ist häufiges, kurzes Wecken des S3 negativ für den Stromverbrauch? Nunja, wenn das Handy aus dem Deep Sleep geholt wird, müssen gewisse Systeme gestartet und initialisiert werden. Das braucht seine Zeit. Genauso müssen vor dem Standby gewisse Systeme abgeschaltet werden. Das braucht auch seine Zeit. Einmal Aufwecken und wieder Einschlafen dauert beim S3 wie auch beim S2 knapp 1 Sekunde, bei der die CPU auf 800MHz/1GHz taktet. Das heißt, jedes mal, wenn das S3 kurz aus dem Standby geholt wird, geht nur für das Starten und Stoppen gewisser Teilsysteme 1 Sekunde CPU Zeit dafür drauf. Und das verursacht eben auch Akkuverbrauch, wenn das Handy vor allem regelmäßig aus dem Standby geholt wird. Wer dazu mehr lesen möchte: Link


Wenn Datenpakete (z.b. eine Whatsapp Nachricht) direkt an das S3 gesendet werden, wird das S3 aus dem DeepSleep/Standby geholt (geweckt). Das ist normal und auch gut so. Je nachdem, was ihr an Apps installiert habt, kommen mal mehr oder weniger solcher Pakete und sie kommen auch eher unregelmäßig.


Problematisch wird es jetzt aber, wenn irgendwelche regelmäßig und häufig reinkommenden Datenpakete das S3 regelmäßig und oft aus dem Standby holen.

Es gibt Kernels, die gewisse Multicast Pakete, die für das Handy nicht wichtig sind, blockieren, damit diese für das S3 unwichtigen Pakete das S3 nicht unnötig aus dem Standby aufwecken. Ein Kernel der das beinhaltet ist zum Beispiel der Siyah Kernel.


Wie oft das S3 durch eingehende Datenpakete aus dem Standby geholt wird, kann man beim S3 in BetterBatteryStats an dem Kernel Wakelock "wlan_wake" erkennen. Und zwar an dem Mittleren (wc, wake count) der drei Werte (c, wc, ec).

Mit Siyah-Kernel an meiner FB-7170 habe ich über Nacht etwa 50-100 "wlan_wake" Wake-Counts.
Mit Stock-Kernel an dem SP-W303V habe ich über Nacht 1700 "wlan_wake" Wake-Counts.


Wann passiert das? Was mir bis jetzt aufgefallen ist:

Beobachtung 1:
Im Originalzustand (Stock Kernel) wird das S3 bei eingehenden IGMPv3 Paketen aus dem Standby geholt.
Mein Speedport W303V sendet etwa 60 dieser Pakete pro Stunde.
Meine Fritzbox 7170 sendet etwa 30 dieser Pakete pro Stunde.

Die IGMPv3 Pakete werden für das IP-TV wie T-Home Entertain und ähnliche Multicast Dienste benötigt.

OK, 60 unnütze WakeUps pro Stunde, sind zwar schon was, aber in meinen Augen noch nicht kritisch.
Kernels mit Multicast Paket Filter wie der Siyah oder der Perseus Kernel blocken diese Pakete und das Handy schlummert einfach weiter, wenn diese Pakete ankommen.

Aber wie gesagt, bei 60 Wakeups pro Stunde muß man jetzt noch nichts dagegen unternehmen.


Beobachtung 2:
Der Broadcom / 0x886C / BT-AMP Bug mit den 0x886C Paketen existiert auch beim S3. Wenn auch er nicht immer auftritt.

Wobei diese 0x886C Pakete an sich nichts Schlimmes sind und auch duchaus vorkommen können/müssen, nur eigentlich nicht regelmäßig 6 / Minute.

Wenn dieser Bug eintritt, wird das Handy alle 10 Sekunden geweckt. Also etwa 360 unnötige Wakeups pro Stunde.

Erkennen könnt ihr diesen Bug, wenn ihr regelmäßig in BetterBatteryStats unter Kernel Wakelocks bei dem "wlan_wake" wake count (wc, der mittlere Wert) pro Minute 5-6 wake counts sammelt.
Verifizieren könnt ihr den Bug, wenn ihr mit Shark for Root mal einen Mitschnitt anstellt, das Handy 10 Minuten liegen lasst, dann den Mitschnitt stoppt und die auf der SD-Karte angelegte shark_dump Datei bei cloudshark.org hochladet. Wenn ihr dann in einem 10 Minuten Shark-Dump dann 60 der Pakete habt, bei denen bei Protocol 0x886c steht, habt ihr das Problem auch.

Der Bug tritt z.B. definitiv nachgewiesen bei Cyanide's S3 an seiner Fritzbox 7390 auf.

Und auch bei meinem S3 (Stock XXLIB Jelly Bean Firmware mit Stock Kernel) an dem Speedport W303V. Sobald ich aber das WLAN von dem Speedport W303V auf meine Fritzbox 7170 umschalte, ist der Bug wieder weg. Es reicht wirklich der simple Wechsel des WLANs. Die wlan_wake wake-counts steigen dann nicht mehr regelmäßig um 6/Minute.

Auch der Siyah-Kernel 1.7b6 mit Multicast Packetfilter hilft bei dem Problem nicht. Es tritt auch mit dem Siyah-Kernel an der W303V auf. Sobald ich auf die FB7170 wechsle, ist das Problem wieder weg.

An dem W303V hängt auch noch ein Fritz-WLAN-Repeater, der das WLAN der W303V "verlängert". Ist das Handy am Repeater angemeldet, tritt der Fehler interessanterweise nicht auf.

Das S3 eines Kumpels ist 100% Stock ICS, BLH3 Firmware, hat das selbe Fehlerbild wie mein S3. Fehler, wenn am W303V angemeldet, aber kein Fehler, wenn an dem Repeater angemeldet, der das W303V-WLAN "verlängert.

Also haben wir momentan folgendes Wissen:

Probleme beobachtet an:
Speedport W303V (WLAN-IC: Broadcom BCM4322) (zwei verschiedene S3s, ICS/JB egal, Stock Kernel/Custom Kernel egal)
FritzBox 7390 (WLAN-IC: Atheros AR9220+AR9223) (Cyanide, inkl. Shark bestätigt)
FritzBox 3270 V3 (WLAN-IC: Atheros AR9220) (Frankenchris, vermutlich anhand der Wakes. (Noch) nicht per Shark überprüft)
(Vermutung) Fritz WLAN-Repeater FWR (schwarz) (WLAN-IC: Atheros AR9220)


Keine Probleme an:
Fritzbox 7170 (WLAN-IC:Texas Instruments TNETW1350A/PSB1350AZGU)
Fritzbox 7270 V2 (WLAN-IC: Atheros AR5416+AR5133) (Schroedinger, vermutlich anhand der geringen Wakes))
Fritz WLAN-Repeater 300E (grau-rot) (WLAN-IC: Atheros AR9382) hinter Speedport W303V
Edimax BR-6228nS (tag)

Interessant hierbei, daß der Fritz WLAN-Repeater das Problem am W303V WLAN "behebt".


Woher der Bug kommt und ob/wie man ihn wegkriegt, weiß ich leider selber noch nicht.
Etwas mehr dazu lesen kann man bei den XDA-Developers darüber LINK1 und LINK2.

Sollte ich noch neue Erkenntnisse gewinnen, werde ich diesen Post hier erweitern.


EDIT1:
Zu den 0x886c Paketen... Ich glaube nicht, daß wir das Problem lösen können.
Mittlerweile gehe ich davon aus, daß es von dem WLAN-Chipsatz des WLAN-Accesspoints abhängt. Zumindest hat der W303V wohl einen Broadcom Chipsatz und das die 0x886c Pakete hängen mit Broadcom zusammen.
Es gibt wohl bei Bluetooth 3.0 eine Erweiterung Bluetooth 3.0-HS, die ähnlich S-Beam funktioniert. Wenn man größere Datenmengen über Bluetooth schicken will und beide Geräte die Erweiterung unterstützten, nutzen die Geräte Bluetooth als Kontrollverbindung, und schalten aber WLAN hinzu und schicken die Daten über das wesentlich schnellere WLAN.
Dazu muss Bluetooth mit WLAN zusammenarbeiten. Oftmals ist ja auch beides auf einem Chip.
Ich glaube das es Kontrollnachrichten sind, die der eine Teil von den Chip an den anderen Teil des Chip schickt.

Die 0x886c Pakete haben als Absender die eigene MAC Adresse der WLAN-Schnittstelle bei der nur ein Bit gekippt wurde und als Empfänger die eigene MAC Adresse. Das heißt das Handy verschickt sozusagen Daten von einer Fake-Absenderadresse an sich selbst.
Das kann eine mehr oder weniger normale Vorgehensweise sein, nur ist es halt Mist, wenn sich deswegen das Handy alle 10 Sekunden selbst weckt.
Wobei ganz sicher kann ich da nicht sein, da ich nicht weiß, wie das System funktioniert. Der Absender der Pakete ist auf jeden Fall eine nicht existente MAC-Adresse. Evtl. könnten die Pakete auch von dem Broadcom WLAN Chip im Router erzeugt werden. Aber in dem Fall wäre die Frage, wieso der Chip die Daten nicht mit seiner eigenen MAC Adresse als Absender verschickt.

Also wie gesagt, das Problem besteht nur an gewissen WLAN-Accesspoints, aber die Daten kommen vom S3 selbst, das sich die Daten selbst zuschickt. Das wird wahrscheinlich sogar intern im Interface ablaufen, sodaß die Daten gar nicht wirklich gefunkt werden. Wobei da bin ich mir nicht sicher.

Ich habe das Problem mal an Gokhanmoral, dem Entwickler des Siyah-Kernels herangetragen, mal schauen, ob er das im Kernel abschalten kann. Wobei dann auch wieder die Frage ist, ob damit dann irgendeine Funktion nicht mehr geht.

Ich denke auch, daß der Router selbst nicht "Schuld" ist. Es kann gut sein, daß die betroffenen Router ein leicht anderes Verhalten haben, was aber völlig standardkonform ist, nur dieses andere Verhalten führt dazu, daß der WLAN-Treiber im S3 ausstickt, was er nicht sollte. In dem Fall trifft den Routerhersteller absolut kein Schuld.

Alles in allem ist der Bug jetzt auch nicht überkritisch. OK, wir haben leicht höheren Standbyverbrauch, aber er ist imho gerade noch im Bereich des Akzeptablen.


EDIT2:
Nach ein bißchen Erfahrungsaustausch bei den XDA-Devs im BBS Thread scheint das Problem nicht direkt aus dem Kernel zu kommen, sondern es liegt in ein paar Broadcom-(Treiber?)-Dateien, die im ROM integriert sind und leider nicht im Quellcode öffentlich vorliegen. Man könnte also sagen, das ist ein Bug in den Broadcom-Treibern und da diese nicht Open Source sind, sondern nur als Binary vorliegen, kann man nicht schauen, wieso dieser Fehler auftritt und man (die Community) kann ihn daher auch nicht abstellen.
Samsung müßte da Broadcom auf die Füße treten und sich neue/bessere Treiber von Broadcom liefern lassen und die dann ausrollen.
Das ist zumindest mein Wissen/Verständnis, was ich momentan von diesem Problem habe.


EDIT3:

Für alle, die das Problem mit einer Fritz!Box (7270, 7390 und andere) haben, dass der Stromverbrauch erhöht ist: Nicht nur der teure Fritz!Repeater hilft. Bereits die Erweiterung des WLAN mit Edimax BR-6228nS (beispielsweise bei Amazon für etwas unter 18 Euro, aber sicher auch bei allen anderen Händlern günstig zu erwerben) hat bei mir den Verbrauch in 6 Stunden Nacht auf 10% statt 30% gesenkt. Und das bei grottenschlechtem Mobilfunkempfang.
Der 6228 als Repeater ist natürlich nicht das Highend-Teil, erfüllt aber seinen Zweck. Ich habe zwei von denen sowieso im Betrieb, weil wir über 3 Stockwerke wohnen und unsere Wände/Decken nahezu ein Faradayscher Käfig sind (beispielsweise keinerlei UKW-Empfang im Bad).

Viele Grüße
Rob

 

[frankenchris]

Super recherchiert Rob

Was mich aber noch mehr interessieren würde was die rx packete sind:


================
Kernel Wakelocks
================
"wlan_rx_wake" (): 1 h 34 m 33 s (5673 s) Cntc/wc/ec)3768/0/3768 15,2%
"battery-monitor" (): 1 h 4 m 5 s (3845 s) Cntc/wc/ec)3872/0/3872 10,3%
"alarm_rtc" (): 47 m 50 s (2870 s) Cntc/wc/ec)2967/46/2801 7,7%
"l2_hsic" (): 35 m 9 s (2109 s) Cntc/wc/ec)4024/156/4024 5,6%
"wlan_wake" (): 10 m 7 s (607 s) Cntc/wc/ec)33844/3533/0 1,6%
"alarm" (): 5 m 10 s (310 s) Cntc/wc/ec)1043/3/0 0,8%
"PowerManagerService" (): 3 m 50 s (230 s) Cntc/wc/ec)1170/0/0 0,6%
Kingdom & Lords
Nick: Frankenchris

 

[Rob2222]

Huhu,

der "wlan_rx_wake" Wakelock hängt auch mit den eingehenden WLAN-Datenpaketen zusammen. Wieviel Pakete da eingehen, kannst Du daran aber nicht erkennen. Über den count (c), kannst Du nur sehen, wie oft der wakelock selbst ausgelöst wurde.
Und über die Zeit kannst Du sehen, wie lange diese Wakelocks zusammen das Handy wach gehalten haben.
Jedes Mal, wenn der wlan_rx_wake Wakelock ausgelöst wird, ist das Handy für 1 bzw. 1.5 Sekunden wach.
Siehe auch hier.
Ich denke über den Wakelock kann man so grob auf die Menge des WLAN-Datenverkehrs schließen.
Allerdings nicht, wie oft das Handy deswegen geweckt wurde.

Gruß
Rob

 

[frankenchris]

Dann werde ich mal gucken warum meine Fritzbox 3270 so rum zickt:

https://dl.dropbox.com/u/73907032/BetterBatteryStats-2012-10-17_034950622.txt

 

[Cy4n1d3]

Selbes Spiel wie bei mir scheinbar
Du könntest ja auch per Wireshark / Shark for Root mal ein Capture machen und nach den 0x886er Paketen suchen...

 

[AndyInBlood]

@frankenchris hast du dein BetterBatteryStats so konfiguriert wie im zweiten Post dieses Threads angegeben? ich frage weil bei dir nicht der durchschnittliche Verbrauch pro Stunde in % berechnet wird.

Nur mal so: Rx steht im Zusammenhang mit Datentransfer eigentlich immer für Receive, Tx immer für Transmit. Das x ist eigentlich nur ein Platzhalter. Keine Ahnung wieso das so geschrieben wird, bin kein Engländer

Mal an die Shark-Experten: reicht es nicht, wenn ich am Interface des Routers schnüffele? Hmmm, hab ja seit ein paar Monaten auch eine FritzBox, kenne mich mit den Teilen aber immer noch nicht wirklich aus. Solange ich keine vollwertige CLI habe ist es eben kein Router sondern nur eine FritzBox Kann ich dem WLAN-IF nicht sagen, das es unknown protocols droppen soll? Ich weiß nicht, ob das ne gute Idee ist weil ich bisher noch nicht nach 0x886c gegoogelt habe, was ich aber gleich mal tun werde.

 

[frankenchris]

Hi rob

Process und Service waren nicht im dump angehakt.

Habe kein Unplugged sondern ein Custom erstellt. Heute morgen habe ich mal ein paar Einstellungen am Router vorgenommen.

Werde heute Nacht mal nen neuen Dump machen.

 

[Rob2222]

Huhu,

zu den 0x886c Paketen... Ich glaube nicht, daß wir das Problem lösen können.
Mittlerweile gehe ich davon aus, daß es von dem WLAN-Chipsatz des WLAN-Accesspoints abhängt. Zumindest hat der W303V wohl einen Broadcom Chipsatz und das die 0x886c Pakete hängen mit Broadcom zusammen.
Es gibt wohl bei Bluetooth 3.0 eine Erweiterung Bluetooth 3.0-HS, die ähnlich S-Beam funktioniert. Wenn man größere Datenmengen über Bluetooth schicken will und beide Geräte die Erweiterung unterstützten, nutzen die Geräte Bluetooth als Kontrollverbindung, und schalten aber WLAN hinzu und schicken die Daten über das wesentlich schnellere WLAN.
Dazu muss Bluetooth mit WLAN zusammenarbeiten. Oftmals ist ja auch beides auf einem Chip.
Ich glaube das es Kontrollnachrichten sind, die der eine Teil von den Chip an den anderen Teil des Chip schickt.

Die 0x886c Pakete haben als Absender die eigene MAC Adresse der WLAN-Schnittstelle bei der nur ein Bit gekippt wurde und als Empfänger die eigene MAC Adresse. Das heißt das Handy verschickt sozusagen Daten von einer Fake-Absenderadresse an sich selbst.
Das kann eine mehr oder weniger normale Vorgehensweise sein, nur ist es halt Mist, wenn sich deswegen das Handy alle 10 Sekunden selbst weckt.
Wobei ganz sicher kann ich da nicht sein, da ich nicht weiß, wie das System funktioniert. Der Absender der Pakete ist auf jeden Fall eine nicht existente MAC-Adresse. Evtl. könnten die Pakete auch von dem Broadcom WLAN Chip im Router erzeugt werden. Aber in dem Fall wäre die Frage, wieso der Chip die Daten nicht mit seiner eigenen MAC Adresse als Absender verschickt.

Also wie gesagt, das Problem besteht nur an gewissen WLAN-Accesspoints, aber die Daten kommen vom S3 selbst, das sich die Daten selbst zuschickt. Das wird wahrscheinlich sogar intern im Interface ablaufen, sodaß die Daten gar nicht wirklich gefunkt werden. Wobei da bin ich mir nicht sicher.

Ich habe das Problem mal an Gokhanmoral, dem Entwickler des Siyah-
Kernels herangetragen, mal schauen, ob er das im Kernel abschalten kann.

Alles in allem ist der Bug jetzt auch nicht überkritisch. OK, wir haben leicht höheren Standby verbrauch, aber ers ist noch im Bereich des Akzeptablen.


@Frankenchris:
Bei Deinem Router besteht das Problem scheinbar auch. Aber installiere vor allem mal eine neuer BetterBatteryStats Version. Da muß man ja die %/h noch selber ausrechnen bei den Dumps.
Aber wie gesagt, momentan glaube ich nicht, daß wir da was ändern können.

@AndyinBlood
Wenn das S3 die Pakete selbst erzeugt und an sich selbst schickt, bringt da leider kein Filter im Router was. Allerdings irgendwas muß ja an dem Router ander sein, daß er dieses Verhalten am S3 auslöst.
Die Broadcom Ingenieure haben sich da schon was ziemlich Komisches einfallen lassen...

Gruß
Rob

 

[AndyInBlood]

@Rob: deckt sich absolut mit dem, was ich dazu herausgefunden habe. Zusätzlich scheint Broadcom nicht gerade gut zu sein was Dokumentationen angeht.
Zusätzlich habe ich diesen ziemliche interessanten Thread bei G+ dazu gefunden: https://plus.google.com/u/0/1050519...dVxPT#105051985738280261832/posts/FV3LVtdVxPT

Vor allem der Post von Andrew Dodds vom 17.1.12. Er macht dafür den Broadcom BCM4330 Chipsatz bzw. dessen Firmware für die meisten, wenn nicht sogar alle derartigen Probleme verantwortlich. Dies ist so ein eierlegende Wollmichsau Chip (laut Broadcom "802.11a/b/g/n MAC/Baseband/Radio with Integrated Bluetooth 4.0+HS & FM Transceiver").

Mich würde mal folgendes interessieren:
1. welche Chipsätze genau sind auf den Routern/ Repeatern? Wie du schon schreibst, muss ja hier auch irgendein Hund begraben sein, der das Ganze begünstigt.
2. muss für das Verhalten Bluetooth eingeschaltet sein?

Aber insgesamt hast du wohl, zumindest aufs S3 bezogen recht: der Impact ist nicht sooo riesig das es sich lohnen würde, hier die aller letzte Energie reinzustecken. Interessant ist es aber dennoch

 

[Cy4n1d3]

Mein Bluetooth ist deaktiviert, hat damit also (leider) nichts zu tun scheinbar.

 

[Rob2222]

Jo, mein Bluetooth ist auch aus gewesen bei den Tests.

Das mit den Chipsätzen kann man ja teilweise googlen. Man muß nur beachten, daß es um den WLAN Chipsatz geht, der nicht zwingen der selbe wie der DSL Chipsatz sein muss.
z.B.:
http://www.wehavemorefun.de/fritzbox/FRITZ!Box_WLAN_3270#Hardware
und
http://www.wehavemorefun.de/fritzbox/FRITZ!Box_Fon_WLAN_7390#Hardware
Und in der Tat, haben die einen gleichen/ähnlichen WLAN Chip von Atheros.

Wohingegen meine FB7170 bei der das Problem nicht auftritt einen WLAN-Chipsatz von Texas Instruments hat.

Ich denke auch, daß der Router selbst nicht "Schuld" ist. Es kann gut sein, daß die betroffenen Router ein leicht anderes Verhalten haben, was aber völlig standardkonform ist, nur dieses andere Verhalten führt dazu, daß der WLAN-Treiber im S3 ausstickt, was er nicht sollte. In dem Fall trifft den Routerhersteller absolut kein Schuld.

EDIT: Habe mal angefangen, die ICs mit aufzunehmen:
https://www.android-hilfe.de/forum/...me-und-mehr.248651-page-139.html#post-4272431

Gruß
Rob

 

[Estoroth]

Vielen Dank und bitte weiter so!

 

[frankenchris]

Jo grosses Lob Rob

Vote for Android president

 

[Pat89]

Ich weiß ich bin hier im S3 Thread... ABER: Ich besitze das S2 und meine "Telefon-App" liegt bei über 35 % Akkuverbrauch.
Seit dem Update auf 4.0.4 hält der Akku nur noch ein paar Stunden.
Bitte um Hilfe!

 

[mi7ck]

Hallo,

gestern habe ich mein Samsung Galaxy S3 erhalten und mich voll Freude daran gemacht es einzurichten (also Mailkonten, Musik synchronisieren, Ein paar Apps runterladen).
Jedoch wurde meine Freude recht schnell wieder gebremst, weil das Telefon sehr viel Akku verbraucht hat. Aufgrund dessen habe ich die Helligkeit ganz nach unten geschraubt und den Energiesparmodus aktiviert.
Allerdings hat das auch nicht viel gebracht.

Über Nacht habe ich das Handy dann einmal ganz aufgeladen. Heute morgen war ich mal für 10-20 Minuten im Internet, auf niedrigster Bildschirmhelligkeit, ohne irgendwelche anderen Apps im Hintergrund und die Akkulaufzeit ist von 97% runter auf 93%. Im Task-Manager unter "Hilfe" stand, dass man das Handy neustarten sollte, indem man die "Sperrtaste" und die "Lautstärke +" Taste gleichzeitig für 8 Sekunden drückt. Habe ich gemacht und als das Handy wieder hochgefahren ist, hatte ich nur noch 80% Akku.

Das ist jetzt nicht wirklích das, was ich von dem 2100 mAh Akku erwartet habe.

Ich habe mir schon ein paar Sachen durchgelesen, unteranderem stand da, dass es bei den ersten Ladezyklen normal sei, dass der Akku recht schnell leer ist. Stimmt das?

Und vielleicht habe ich ja noch was übersehen was so viel Strom verbraucht aber die ganze Zeit bei mir im Hintergrund läuft?

Ich habe hier nochmal ein Bild von meiner Akku Nutzung:

Directupload.net - 9ytqzsqz.png