yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] Greedyfly:
Fair enough.

Background is I am getting between a 9-10% drop off over about 3 and a bit hours, and whilst that seems okay it isn't close to the numbers some are getting here.

I am running the Omega ROM v7 and Siyah kernel. Any other technicalities I am not sure about.

Below attached are the hopefully correct dump files plus the battery data.

If there are any details I have missed please ask.

Otherwise please can you identify some of the issues that might be causing the drain.

Note on the second battery pic it does say charging but it has literally just been plugged in.
[BetterBatteryStats] Karpfenhai:
@Sven, rc8 is great, all references are resolved by default with no issue.

One small misbehaviour, if bbs is active on screen and you lock the screen ( new sco reference will be set) it becomes pretty much unresponsive after unlocking. System asks to wait or kill, after waiting it reacts as expected.

It's no issue or dealbreaker just a hint!

Perfect work, first time nine rc's!

Tapatalked from my Samsung GT9100
[BetterBatteryStats] itsLYNDZ:
Could someone look at my BBS? It seems my battery is just dropping but im not really using the phone.

Also, can someone suggest a facebook app? Ive tried Friendcaster and Fast for facebook, but didnt like the layout for either of them.
[BetterBatteryStats] xelra:
Before doing any analysis, try imo messenger beta. I've tried them all and this one isn't just the best, it's also the easiest on the battery. And it can even do Skype.

Less than 150 wakeups per day with 5 im accounts connected on idle.

You used your phone. BBS is for analyzing battery hogs through idle usage. Idle!

So the dump is too inconsistent to tell you the specifics.

2 tips though I can already give. Get rid of the ebay app. You are probably using Tasker in a bad way. Rethink your profiles and how they cause wakelocks.

After you did that, post another dump with 4 to 6 hours of idle only.

Charge 100%, unplug, go to sleep, wake up, dump. Then you can use your phone.

P.S.: I hope I didn't sound rude, I think I did. But I'm too lazy to rewrite my post now. It wasn't my intention.
[BetterBatteryStats] andry23jsv:
Here is the correct one (hope)

eBuddy XMS isn't eBuddy (like nimbuzz and the one you talk about).. it's a whatsapp like app! ;)
[BetterBatteryStats] jabz:
Ok thanks, would it be better if I change Exchange to Push during on peak hours and manual for offpeak?
[BetterBatteryStats] chamonix:
I don't use exchange so I unfortunately I don't know any tweaks. Either the guys here have a hint or you could use the search
[BetterBatteryStats] chamonix:
In that reading again most of the time awake is due to you using the phone. Please follow the instructions from post #1 to provide an idle dump
[BetterBatteryStats] kaushikd:
help with stats

Can anyone help me with the attached stats. I'm not able to understand. Does this looks okay?
[BetterBatteryStats] chamonix:
What is it you don't understand? Maybe you should have a look at the two first posts on providing proper info and the how-to if you want to learn how to read bbs.

Edit: and if this was my phone I wouldn't be satisfied
[BetterBatteryStats] Greedyfly:
Nope. Not rude at all. Sometimes more 'matter of fact' answers get the job done faster so thank you.

So I have just charged my phone and will endeavour to leave it 4 hours before getting a dump. However, I obviously have no control over those who text or call.....Does this create an issue?
[BetterBatteryStats] Spiralzz:
I dunno if its happening with you guys, but when I open bbs, it opens pretty fast, but when I switch to kernel wakelocks or partial wakelocks or anything, it just keeps on "computing".... I've cleared data and cache for the app, but doesn't fix...
[BetterBatteryStats] kornnflake:
Could someone please take a look at my BBS? It seems my battery is just dropping but im not really using the phone.

Thanks!
[BetterBatteryStats] Karpfenhai:
You are suffering the usual candidates :)

Way to much sync.. and location services.

- disable all sync and re-enable only the things you really need, check with care.

- Use K9 set to pull for emails

- Facebook is a known drainer, try firendcaster instead.

- disable latitude, give Altitude a try if you can not surrender location service

General advice:

- use another modem driver (Baseband) try KI4.

- try another kernel, are you on AOSP or MIUI? Try to undervolt your current kernel, set an upper limit, 800 Mhz are good ;)

- Disable Autobrightness, for low light conditions, use screenfilter additionally.

Next time, produce an Idle Dump! Read the first and second post for an how to!

Anyway, 40 mins overhead out of 17 hours is not too bad! ;)
[BetterBatteryStats] kornnflake:
thanks for your fast reply. gonna check the Idle Dump next time ;) I used my phone for navigation that's where all the latitude useage came from. i'm on the cm9 kernel and set an upper limit to my cpu now, thanks for this advice.
[BetterBatteryStats] Rob2222:
@Tungstwenty:

One question to the exclusive wakelock system. You can switch them on and off in ExTweaks when using Siyah, for example.

I thought, for comparing, I make a exclusive "since custom ref" dump, switch the option, and then directly make a non-exclusive dump, soon after that.

But then I came to one thing... when having a exclusive custom reference point (set while in exclusive mode), can I then compare that exclusive reference point against the "now" reference when in non-exclusive mode?

I assume exclusive and non-exclusive mode have different data in the wakelocks.

So I have to stick with the mode, in that the references got created, when I want to have correct kernel wakelock data, right?

Best Regards

Robert
[BetterBatteryStats] andry23jsv:
I'm sorry! Now, after a night, it would be ok.

However, the problem is when I use eBuddy XMS.. it increases its time in Partial wakelocks..
[BetterBatteryStats] xelra:
That's why I suggested you do it over night. ;)

Don't go below 800 MHz though. It can produce numerous problems.

This really saves a lot of battery while using the phone, despite undervolting.
[BetterBatteryStats] Tungstwenty:
Exactly, the stored baseline numbers will skew the data if you alternate the mode without starting again.

What I did when I wanted to have a comparison, was rebooting (exclusive ON), letting it idle during the night, dump file, then change the mode and dump a new file.

The results might be still a bit different than they should, but since the initial values should be close to 0, it's probably good enough for you to have an idea of the 2 different measurements.
[BetterBatteryStats] Greedyfly:
You didn't expect me to read ALLL of your response did you? Tyipcal ;)

Apologies.

However, have gotten to 2.40 hours with nothing incoming so I might manage this as it goes.
[BetterBatteryStats] Karpfenhai:
cmon

Since 11 h 46 m 43 s

Deep Sleep (): 11 h 18 m 56 s (40736 s) Ratio: 96,1%

Awake (): 27 m 47 s (1667 s) Ratio: 3,9%

Screen On (): 21 m 24 s (1284 s) Ratio: 3,0%

4 Mins ebuddy..

so...

6 mins 23 sec overhead out of 11 hours 46 min. minus your 4 mins Ebuddy lefts over 2 !!! Mins of background noise, thats is quite perfect! :good:

Well done, enjoy your phone!
[BetterBatteryStats] andry23jsv:
Thanks for the reply!

Your analysis is almost ok, BUT the time of eBuddy (4 m 28 s) isn't with screen off.. That's my question: eBuddy increases its time in wakelocks when it's open.. Why? Is it normal? Viber doesn't do this..
[BetterBatteryStats] itsLYNDZ:
Here is mine. I noticed Mobile for Facebook was using up quite a bit. Got rid of that. Anything else? I know it was only for a few hours, but I was hardly using it. It was just sitting on my desk at work.
[BetterBatteryStats] Simba501:
Nothing really.
[BetterBatteryStats] itsLYNDZ:
I have an extended battery and custom rom but I'm still not getting what others do for battery life
[BetterBatteryStats] ahhoe:
See If your hp is affected by the l2_hsic kernel wakelock.
[BetterBatteryStats] itsLYNDZ:
I don't know what that means. What is that and how would I check
[BetterBatteryStats] nam3less:
Alright, I woke up this morning, unplugged my phone, and got to work.

Checked BBS about 10 minutes later to find that the "since unplugged" reference didn't refresh from last night. So I did my usual switch between "since _______."

Since unplugged isn't showing deep sleep. Furthermore, when I plugged my phone into my computer to get you the logcat, the since unplugged didn't refresh. I had to switch to a different "since" and back again. It is again not showing deep sleep.

Log cat: http://dl.dropbox.com/u/13641148/LogCat_Default_Tue0717_91735.txt

Same settings as before with defaults of "Other" and "Since unplugged." And here's a link to the ROM. Just stock AOSP. http://xdaforums.com/showthread.php?t=1763823

Sorry for making this difficult :P
[BetterBatteryStats] jeffreii:
Hey guys - please check out my latest test...battery dropped 24% in 2 hours with very little usage...the twist here is that about halfway through I turned off my wifi. If you recall from my last posts I had a ton of wlan_rx_wakes. I decided to see if the plummeting battery continued if I turned off wifi and here's what I got. See log attached and screenshot. 653k deleted_wakelocks in 2 hours?! Needless to say the battery continued to plummet even with wifi off...so it's something else.

Whenever this happens I reboot my phone and it returns to normal 1-2%/hour discharge.

Thanks!

http://img6.imageshack.us/img6/2973/20120717091404.png
[BetterBatteryStats] mammenj:
I am glad to report that chrome workaround has fixed the major battery drain, keeping fingers crossed :-)
[BetterBatteryStats] chamonix:
Correct, you can not compare two /proc/wakelocks files in a timed sequence but containing different data.

I plan to add a check on what setting was used (discrete or normal) as this matters to whom reads the dump but as a matter of fact it would be good to write that info to the reference and bring an error if this happens. It could save us a lot of trouble trying to find non existing problems
[BetterBatteryStats] yhrn:
Cool! I haven't seen it since either but I think I'll wait for a week or so before I feel reasonably sure that it's gone for good...
[BetterBatteryStats] abtamis87:
Gf had the same issue on her one x. Battery life is now back to normal since I applied the fix. :)
[BetterBatteryStats] Rob2222:
I wonder if this way would create correct results also:

Unplugging from power (for ref creating) in non-exclusive mode, then switching to exclusive mode and making a custom ref (exclusive).

So now we have a non-exclusive ref (since unplugged) and a exclusive ref (custom ref).

Then letting it idle an create a dump since custom ref (exclusive), switch back to non-exclusive and create a dump since unplugged (non-exclusive).

Best Regards

Robert
[BetterBatteryStats] Tungstwenty:
Good idea; it should work, yes

---------- Post added at 05:49 PM ---------- Previous post was at 05:44 PM ----------

All that activity of the "deleted_wake_locks" entry corresponds to what happened to all the wakelocks that existed at some point in time (e.g. wlan_rx_wake) and at some point were deleted due to the driver unloading or something similar). Once a wakelock is deleted it won't generate any more activity.

If you have the phone in a certain state (such as WiFi off) and these values keep increasing, the only way that can happen is if some KWLs keep getting deleted and they had activity before that deletion.

---------- Post added at 05:56 PM ---------- Previous post was at 05:49 PM ----------

chamonix,

I'm starting to worry a bit here that things will start going ad-hoc and in some time will be somewhat uncontrollable (or unfixable if the confusion is found to be too much later on).

Your comment implies introducing code in BBS that is very specific to this kernel, and worse, to the currently existing interface which might change :(

I was thinking about the comments I made earlier and perhaps the solution of having another interface at /proc/wakelocks_detailed or whatever, where all the relevant stats would be in a single line, would likely be the best way.

What's your opinion on having you and a couple of other power-analysis gurus over here agree on what could be interesting (existing stats + discrete stats side by side? something else?) and when Gokhan returns from holidays I could check if he agrees on changing it and eventually talk to the other kernel devs? It still wouldn't be a linux standard, but at least it would be subject to broader validation both from the user's end-point (the power gurus) and from the kernel side (at least a couple of devs)...
[BetterBatteryStats] itsLYNDZ:
What does this mean and how can I check it
[BetterBatteryStats] Karpfenhai:
Check bbs for this WL:

if it has an high amount, it indicates a dirty network and would explain some drain.

Tapatalked from my Samsung GT9100
[BetterBatteryStats] itsLYNDZ:
Is there a way to fix it
[BetterBatteryStats] Rob2222:
Thx for the explanation, even if it wasn't directed to me.

I understand your explanation so far, but I can not get a conclusion what that means for the real case.

When a deleted wake_lock can't generate activity, then how can deleted_wake_lock accumulate time? :confused:

Why do some configurations have deleted_wake_lock time and some not?

Best Regards

Robert
[BetterBatteryStats] chamonix:
You are right, such changes would be depending on an implementation (interface) that is not standardized but that's the way it is with emerging standards.

I am no kernel dev and know nothing about how to proceed such a case, what discussions would have to take place about the acceptance of the patch, if there is even something like an RFC describing the content and format of /proc/wakelocks, if it's realistic to suggest an extension of it, if putting a second wakelock file for "discrete" wakelocks in /proc is the right way to do things.

It would be indeed a good idea to get the right people for that discussion together and to discuss how to handle it, either from a strategic or from a tactical point of view or both.

As a minimum requirement I would like to asap make sure that the reader is able to understand what he reads when he looks at what BBS summarizes from /proc/wakelocks. This is based on the fact that the implementation is already out there and I want to avoid that things are misinterpreted because a piece of the puzzle is missing. For that if would be sufficient to read the sysfs file controlling the output and, in the dump and/or on screen, give a hint about it. The case of changing the processing of KWL between references is a theoretical discussion in my eyes and I wouldn't see the error handling for that as mandatory.

From that standpoint my suggestion:

- I implement a minimum solution, in the dumpfile, telling the read whether it is a discrete or plain-old KWL reading (it would be nice if you could recap the sysfs implementation in a short PM so that I don't have to scan the thread back)

- I leave it up to you to consult about how to lead a discussion about the future of that patch among kernel devs; if you feel my input is of interest and you peers feel the same I would be happy to join but that's your call because it's not my terrain (I'm just a java guy with a little bit of understanding about performance tuning)
[BetterBatteryStats] Greedyfly:
I managed to get roughly three hours of pure idle. It's short of the 4-6 you suggested but I am hoping you can analyse some of this tonight. I am going to change my ROM to a newer based one and then try this again tonight. In the meantime please see attached and let me know if you need any other information. And thanks again for any help provided by the users on this forum.
[BetterBatteryStats] chamonix:
Wow, we just passed the million views. Congrats ou you guys for keeping this thread alive and investing your time to make BBS a better tool
[BetterBatteryStats] Tungstwenty:
Let's get an example (forget about the exclusive/discrete stats, let's use the normal ones). WiFi is the best example, at least in my setup.

Turn WiFi on. Let it transmit (or idle) a bit so it starts showing in the KWL BBS view.

Then turn off Wifi. The wlan_rx_wake and wlan_wake KWLs are destroyed, and whatever values they had are combined and joined together in the "deleted_wake_locks" pseudo-KWL. It's not a real KWL that is activated/deactivated, but rather a way for you to know the total of all KWL activity for the ones that no longer exist.

Now turn WiFi on again. The 2 corresponding KWLs will start showing in BBS, after they have generated a bit of activity. But don't confuse these with the other ones that were deleted already. Despite the fact that they have the same name, they're different instances with completely independent values.

After you turn off WiFi, they will be once again merged into the totals in "deleted_wake_locks". And that's the only way that those values change.

One caveat: if you're using Siyah with the changes I introduced - even with the regular stats active - the wakelock code will keep track of the individual values of the last 2 destroyed KWLs before moving them to the "deleted_wake_locks" totalizer. This is in order for you to at least see a part of what happened and where do these deleted ones come from. You'll have "deleted: wlan_rx_wake" with its individual values when it was deleted. Whenever new ones are deleted, those that are occupying the 2 slots are moved to the grand total to make room for the most recently deleted ones.
[BetterBatteryStats] superbobup:
Congrats to you for making this great tool ;)
[BetterBatteryStats] :
This superb tool should be included in android by default :) excellent support on the thread too, I couldn't dream anything better!

Sent from my SGS2 - SlimICS Rom & Fluxi Kernel
[BetterBatteryStats] jbeef86:
Can someone please take a look at my file dump? It shows that I have 5 hours of deep sleep and 2 hours of awake. I haven't used my phone for more than 30 mins today. It has been like this for a while now with that ratio. Like 9 hours of deep sleep and 4 hours of awake regularly.

Thanks!
[BetterBatteryStats] Rob2222:
Thank you very much for that perfect example/explanation!

Maybe Sven should add this example to the knowledge base article, if its OK?!

Best Regards

Robert
[BetterBatteryStats] Rob2222:
May I add a example for discussion/understanding exclusive/non-exclusive kernel wakelocks?

I dumped this as suggested, "since_unplugged" ref+dump in non-exclusive mode and "since_cust_ref" ref+dump in exclusive mode.

Idle time was rough 2 hours, "awake-screen" time is 10 minutes.

What I wonder.... when adding kernel WL + partial WL of exclusive stat, I did not reach the 10 minutes. Is this normal?

Best Regards

Robert
[BetterBatteryStats] Nightshadow931:
Is this a bug ?
[BetterBatteryStats] analyst783:
What is supposed to appear under the network tab?

I'm running 1.9.0.0 rc8 (and have run a few other rcs for 1.9) and have yet to see anything at all appear under the network tab (or in the report) whether overnight or just for a few hours. I've got a moto DX running CM7 on GB.
[BetterBatteryStats] jeffreii:
Thanks again for taking the time to respond to my logs/screenshot. Seems like this is normal activity despite the seemingly-absurdly-high 653,000 count on deleted_wake_locks. I guess there are no further clues as to what's causing my battery drain yet. I'm thinking it might be easier, at this point, to start disabling some apps when this happens to see if I can find the culprit that way...I love BBS for what it does but right now it's not getting me the answer I need.

Thanks again for all your help.
[BetterBatteryStats] yhrn:
Great explanation! I very much agree that the current KB entry would benefit from this example.

I really appreciate your knowledge on different KWLs and your willingness to explain. I have one more that you might be able to provide some insight on :o - "sec-battery-monitor". It's typically my no. 1 KWL (not counting the PowerManagerService placeholder) now that I've managed to get rid of a lot of drainers (courtesy of BBS of course). A pretty typical reading after 16 hours usage:

"sec-battery-monitor" (): 11 m 47 s (707 s) Cnt:(c/wc/ec)1089/1040/0 1.2%

Any idea what it's all about?
[BetterBatteryStats] chamonix:
That is indeed a valueable insight. Would you mind reauthor the deleted_wakelocks article on github?
[BetterBatteryStats] Tungstwenty:
By having a look at the kernel sources I can see more or less what's it about, although the exact details are not that easy...

Most drivers register an interrupt to be called whenever the hardware they control has something to tell the OS, and to wake it up if it's asleep. For simple and quick responses, the CPU is turned back on, stuff is done, and it goes back to sleep - and we won't even see a KWL firing up ... I can see some examples of drivers that register hardware IRQ handlers and don't use KWLs at all; they just read and write data to the hw whenever the interrupt occurs. Potential for situations where there are (expensive) sleep-wake transitions that aren't measured in BBS.

For things that require a follow up, it's done in an asynchronous way - the IRQ routine activates a KWL to prevent the device from sleeping, requests a work queue to do something with the received info from the hw, and exits handling the interrupt. The queue will execute slightly afterwards and finish the job.

Now for this concrete KWL, which is within the battery driver, it also uses this scheme of having the wakelock being activated so the asynchronous handle of messages can complete before the device might go back to sleep happens in a number of situations:

* battery capacity changed (dropped by 1% perhaps???)

* capacity reached a critically low value (a particular case of the former, perhaps)

* health info changed (related with battery temperature)

* whenever the battery driver resumes after a suspend - meaning, whenever the phone resumes from deep sleep!!!

In all of these situations, the "sec-battery-monitor" KWL will become active until the worker has the time to perform these operations:

* check the temperature and perform some actions in case of out of certain thresholds

* check charging status, battery full, cable type, cold, overheat, overvoltage, etc.

After all these checks and updates, it finally releases the KWL and the device is eligible for deep sleep again.

Well, this is only the general idea as I have no way to check in more details based on bare static code. But it should be enough to understand that there's not much that can be done to change the behavior of this KWL (or at least not that I can see)

EDIT:

Additionally to sec-battery-monitor, the battery driver also uses 2 other KWLs:

"vbus_present":

it's permanently locked whenever a cable is attached, and its locked with a timeout of 5s when the cable type becomes "NONE". There's an additional exit path that logs "Invalid cable type" and that doesn't bother releasing the active KWL. I'm not sure when/if it happens, but if it does when there's dust or something in the connector, it might explain those situations where people complain that they need a reboot to release vbus_present. Running "dmesg" and grepping for "cable" might show something, who knows

"sec-battery-cable":

Activated in the IRQ routine whenever a cable is plugged or unplugged, and released after the worker routine updates the current status. Should have a negligible count and lock time, unless you (dis)connect the cable a few hundred times rapidly.
[BetterBatteryStats] sewe:
Only problem i have right now and i don´t know if it is a problem but gosms is giving me some alarms on com.jb.schedule.private.box.

Does someone know what it is?

32 in less then an hour, can´t be good right?
[BetterBatteryStats] Tungstwenty:
Done; let me know if you'd like it to be more verbose or if should be revised for more clarity.