yashsingh1/xdaforums huggingface dataset:
[BetterBatteryStats] :
Thanks! I was saying 12 hours from my personal experience and looking from many feedbacks in many forums.. sorry if it seems misleading..

2 questions:

1) how to determine whether our carrier supports FD or not?

2) you said " I have FD disabled since my carrier doesn't support it but i still see the wakelock,"

---- how do you disable FD? and what is the indicator to show that you still have wakelock despite FD disabled?

This is getting interesting
[BetterBatteryStats] Recallza:
I've been monitoring my battery status so far,

I've lost 5% in 3 hours

So that works out to be about 2.5 days if my phones idle.

Getting CPU Tuner to put my phone into flight mode when phone isn't active has made a HUGE difference!

Yatta! :D
[BetterBatteryStats] :
Thanks! this is getting too technical for me. It's not in Rappaport's textbook :)

i think those without in depth tech knowledge unlike Robert will give another opinion saying that, "FD is no good bcos the conn has been made in just few seconds and stop. There will be too many FD instances. This could prevent phone from going to deep sleep - consumes more battery"

well, I'm no tech person. Thanks for the knowledge! :thumbup:
[BetterBatteryStats] Rob2222:
@ibnmurad:

Yes, I know, I am sorry about that.

As your own tests state, that enabling FD in your mobile does not worsen your battery drain, I think it is safe to say, that you can let FD enabled.

Yes, FD enabled maybe spends some more cpu power due to FD wakelocks but in the same time you save energy by switching faster to a low power RRC network state.

Best Regards

Rob
[BetterBatteryStats] :
I think it depends on how you use the phone connection. I'm constantly on UMTS - HSPAP network, syncing everything + notification during my sleep time too :eek: (unlimited data plan). I'm not worried about higher battery consumption. What I was looking for is the optimization without letting do good mobile data connection. If within a few days monitoring BBS dump data resulting better battery life, than I will keep FD enabled, regardless what people are saying.. different usage, different phone, different network place.

I think most people who are really afraid of enabling FD are those who are Not consistently or most off the time not using mobile data. I'm using data 24/7. I want to receive emails asap. For example, I think people who rely mostly on wifi connection should disable FD. Just maybe..

Thanks.
[BetterBatteryStats] stuart0001:
Isn't that using a sledgehammer to crack a walnut. Not much point in having a phone if you have to effectively turn it off. For instance, you won't get any incoming calls.
[BetterBatteryStats] xelra:
I thought you were on O2 Germany. They support FD in all its glory.

EDIT: Never mind. I just saw in your profile that you are with E-Plus.

Just to contribute to the discussion with FD. Quick and dirty for the regular users. If your carrier supports FD, you should have it enabled.

Why?

Because FD will save you lots of battery when you actively use the connection. Especially when pushing and transferring little chunks of data.
[BetterBatteryStats] palmy999:
Hi Chamonix,

Attached my BBS dumo file for your comment/feedback.

Thanks

Palmy
[BetterBatteryStats] Rob2222:
@xelra:

BTW, this is one of the last things, I am not 100% sure.

What means "the network support FD"...

Does that mean, that the network used NCFD to switch the mobile back fast to a low power state, even when the mobile doesn't requested this (like my E-Plus sample)

OR

does that mean the the network is able to handle ASCR request by the mobile without negative influence?

There were some situations, where some networks were configured in some way, that they ignored the switch-down request by the mobile and this leads to huge battery drain of the mobile trying ever and ever again to switch down.

Best Regards

Robert
[BetterBatteryStats] Karpfenhai:
Robb i will answer this later tonight more in detail. After i read your sources.

Just some information, e-plus and o2 do not support fd in their networks in Germany yet. Are u sure about o2? Great mess then!

Vodafone and t-mobile do!

Your last statement describes the situation correct, that's why it should be disabled.

Thx for your links!

Tapatalked from my Samsung GT9100
[BetterBatteryStats] Greedyfly:
Simple question then. My UK network (Orange (and that includes T-Mobile now) UK) does not support Fast Dormancy in the UK as yet - I have contacted them twice to confirm. Therefore is it better to turn FD off or on.

For those wanting to turn it off or on there is an app in the playstore https://play.google.com/store/apps/details?id=com.gokhanmoral.fastdormancytoggle.i9300&hl=en
[BetterBatteryStats] beggar23:
Hi.

As mentioned yesterday I have a kernel wakelock "GPS" and no idea what to do in order to make it disappear.

Today it happened again and so I attached this dump file.

Thank you for having a look!!!
[BetterBatteryStats] Robot12:
...Quote myself.....;)
[BetterBatteryStats] gr1ff89:
Hi!

Can you help me! When i turn wifi ON the process Event Log Service and GTALK_ASYNC_CONN, GTALK_CONN drain a lot of battery! But i have deleted Gtalk.apk.

help me pls!
[BetterBatteryStats] Rob2222:
Well,

it depends what you mean with "support FD"...

(a) If "support" means NCFD, then my E-Plus home cell supports NCFD as it seems, cause when disabling S3-FD the network puts my phone into PCH 10s after data transfer. (VF needs 40s to put me to IDLE)

(b) If "support" means ASCR compability, this also works on my E-Plus home cell. When enabling S3-FD with 5s timeout, the network puts my phone into PCH after 5 seconds. When changing the timeout value to 2s, the network puts my phone into PCH after 2 seconds.

So, don't care how you interprete "support", this E-Plus cell "supports" it. Even more it uses PCH as low power state. :)

While this Vodafone cell only "supports" (b) and puts me in IDLE as low power state. (which is more worse, cause it nees 2.5s to get back "on air" while from PCH it just needs 0.5s)

In my opinion this "my network support FD" is just a marketing sentense to have an answer to the customer.

In reality it's a little more complex.

EDIT: One more source: Link

Best Regards

Robert
[BetterBatteryStats] Recallza:
Lol Stuart,

Literally after I sent my previous post I slapped myself in the face and said "Doh" - I realised I wouldnt be able to recieve phone calls.

So what I did was Rather disable flight mode, and disabled wlan, bluetooth, auto sync when screen is off and set it to 2G.

Hahaha.. I laugh at my idiotic self :p
[BetterBatteryStats] tylerdurden83:
Can you add a filter for partial wakelocks?

For example, when I stream music via bluetooth to my car's stereo, I'd love for that wakelocks to not be counted in my awake / screen on ratio.

Cheers!
[BetterBatteryStats] Lownita:
I get "no reference since charged yet" for every state but custom ref. For kernel wakelocks and network and CPU states. Using cm9 worth siyah kernel.

Gesendet von meinem GT-I9100 mit Tapatalk 2
[BetterBatteryStats] Tungstwenty:
Today I noticed the exact same situation.

I did a reboot at 17:08 today and the 4 ref files were created. The app also showed the correct data (example: KWLs).

Some time after that I noticed it complained about missing reference data, but the files were still present in the same directory.

After getting the logcat I unplugged USB, plugged back in, and the "since unplugged" ref tile was recreated (newer date) and it started showing values for that ref, but not for the other 2 even though the files are present.

Even though the custom_ref and since_charged_ref might eventually never been set after I have installed the BBS version I have (RC9 still), they do have date of the 17:08 reboot. Also, even forgetting about those, since_unplugged_ref was definitely updated and it still stopped working, when it was before :confused:

I attach 2 logcats filtered for the BBS pid (one before the unplug, when the since_uplugged_ref had stopped working; the other after unplug when it was back working) and also the current ref files except since_screen_off.
[BetterBatteryStats] Karpfenhai:
Robert you did a brilliant research, well done! I do still think the secril_fd wl is related to the "embedded" fd and not rip the carrier one. ...have to read further later..

You can check it by yourselves! But handle with care, it's the service mode!

Tapatalked from my Samsung GT9100
[BetterBatteryStats] Rob2222:
Karpfenhai:

I think its not as easy as that you can draw a conclusion just of the PCH state. See this link from the same blog from the italian carriers.

Vodafone.it uses (used) PCH but before PCH they let the phone 45s(!) in FACH state. :eek: This is not really "fast" dormant, even if they use PCH.

So in this case of this VF.it cell the user should enable FD, even if you see PCH state.

It depends on the network and even more each cell can be configurated different.

Also, according the last comment on this blog PCH was used even before FD-3GPP-R8. The comment is worth reading, also.

FD is really complex. :eek:

There are still some things left, I didn't understood fully.

Have fun reading. :) I am happy when I am not the only one who is investigating this.

BR

Rob
[BetterBatteryStats] EH15:
Here it is
[BetterBatteryStats] akarol:
My GS3 is not showing any Kernel Wakelocks since 1.9 update. I know that you guys are aware of this already. However, rebooting and plugging/unplugging isn't helping either. =/
[BetterBatteryStats] rold50:
android os keep awake

Hi,

I'm getting big battery % in android os with big keep awake time. Do you know what's causing it?

I have attached the screenshots and dump of betterbatterystats.

Thanks!
[BetterBatteryStats] chamonix:
As you didn't provide any log it's a shot in the dark. I'd guess maps together with wifi on. It this does not apply please provide a log
[BetterBatteryStats] chamonix:
Correct, because there was an inconsistency in the previous version because of a use case I did not think of. This inconsistency lead to discrepancies between some readings, causing lots of question. This bug was now fixed.

The reason behind that: the kernel resets its counters at boot and as bbs relies partly on kernel counters there is no way to compare their values before and after boot.

I honestly didn't think that would generate so many questions (I boot about once every 2 weeks) but I plan to add 'since boot' in the next version for you to have at least one consistent reference after a boot without plug/unplug
[BetterBatteryStats] chamonix:
The message may be incorrect but the sense is: Since you booted the battery was not charged to 100% and/or you haven't plugged/unplugged your charger. Therefore there is no way to show data since charged / unplugged.
[BetterBatteryStats] chamonix:
Could you please provide a logcat?
[BetterBatteryStats] Karpfenhai:
I try to boot almost never, only for flashing new kernel :)

The idea it's good, b/c many people charge their phone turned off or have a spare battery charged in a dock.

+1 for since boot!

Tapatalked from my Samsung GT9100
[BetterBatteryStats] Karpfenhai:
You have a lot of background traffic which keeps your phone awake, therefore also the fd wakelock happens.

Try to reduce the poll rate.

To save power it might be useful to change the baseband i recommend ki3 or ki4. You're using kh3, nice, because of the non heating best modem ever voodoo? I'll try that too.

Try an undervolted kernel.

Good luck!

Tapatalked from my Samsung GT9100
[BetterBatteryStats] Karpfenhai:
It's your background activity like google +, mail sync, google sync, network location service.. The usual stuff :), decide by yourself what do you really need? Root your device if possible for a fully featured dump.

Good luck!

Tapatalked from my Samsung GT9100
[BetterBatteryStats] Karpfenhai:
@Robert, thx for non taking my harsh words personally! Today I've learnt many interesting details about fd and it's background!

Here is my new theory:

At some days i almost done see the secril-fd wl, mostly then if I'm at home with edge only.

At work, where my phone often switches between edge, 3g, H and H+, it appears quite often.

So maybe (grey theory) switching between the different umts states causes this wakelock? could this be plausible?

Will try to confirm tomorrow by setting my phone to wmdca only.

Tapatalked from my Samsung GT9100
[BetterBatteryStats] Lownita:
I usually charge my phone while off to 100% overnight, plug it off and boot. Perhaps that's the problem? Worked with previous version though.
[BetterBatteryStats] Rob2222:
@Karpfenhai:

Fast Dormancy is 100% a UMTS/3G (3G,H,H+) feature.

On 2G (G,E) Fast Dormancy doesn't exist. 2G is totally different.

So you can only see Fast Dormancy (and the FD WL) in action on 3G networks.

Working Fast Dormancy on S3 with 5s timer works in that way:

Last Packet transmitted ===> after 5s FD Timer without new packets ===> Mobile unit requests switch back to low power RRC state ===> RNC grants request and both switch down to RRC state PCH or IDLE

So for my understanding it is not unusual, that such transitions with timers need wakelocks.

The point is, that this occurs after most or even each data transfer. So the amount of secril_fd-wakelocks corresponds direct with the amount of data traffic. Or, to be more precise, with the amount of data traffic ends. So burst traffic for 1s each 60s will trigger FD one time each minute. While a large download over 10 min just triggers FD once at the end.

So, once again for my understanding a working FD implementation maybe consumes some power due to kernel wakelocks but in the same time it conserves power due to switching the RRC state after a transmission faster back to a low power state.

Power consumption of RRC states in relation to RRC idle state: IDLE (1x), PCH (1-2x), FACH (50x), DCH (100x)

BR

Robert
[BetterBatteryStats] chamonix:
Yes it did but that's also the reason for many inconsistencies (e.g. deep sleep > since). The reason is that the kernel counters are reset at boot so there is now way to compare stored counters (references) from before a boot to the ones collected at any time after the boot. To make sure the data is always consistent the references are deleted at boot time (that action was not there before and that was a bug).

As I already wrote yesterday I will provide "since boot" for the kind of use case you mentioned
[BetterBatteryStats] chamonix:
A little OT but not that much ;)

I have good news for all you guys struggling with Wifi due to the overhead caused when it's left on (rx wakes but also maps caching): I will release a first beta of "Better Wifi on/off" soon.

It is an agent taking care of turning Wifi on/off based on simples rules like "turn it on when screen goes on but don't leave it on if it doesn't get an IP within 20 seconds" or "turn wifi off 10 s after screen goes off and if not on a/c".

Edit: Better Wifi on/off will be free with ads but fully featured, a "support the dev" version turning off ads will follow for a modest price

Stay tuned!
[BetterBatteryStats] chamonix:
Sure: https://github.com/asksven/BetterBatteryStats/issues/211

I have read somewhere that the batteryinfo service is buggy as releases are not always captures but I guess the kernel has that info as well
[BetterBatteryStats] akarol:
I'm not getting any alarms listed on my Nexus 7. It's completely blank. I have reinstalled and plugged/unplugged the device in to no avail.

Sent from my amazing Nexus 7.
[BetterBatteryStats] akarol:
Sure thing. I'll get to it.

Sent from my amazing Nexus 7.
[BetterBatteryStats] melvinaury:
I include the dump file from the Cappy from my Wife with Stock GB rooted. The problem that we have is that the phone turn on the screen fro several seconds, the go off in a cycle and the don't go to deep sleep.
[BetterBatteryStats] anshmiester78900:
Guys i facing great battery drain .! Android OS is taking much of the battery here r the BBS LOG plz help
[BetterBatteryStats] bigee1212:
really missed these stats from froyo. works like a charm.
[BetterBatteryStats] xelra:
I think that the FD wakelock is especially high when you move around, handshaking with new towers all the time.

Otherwise the FD wakelock goes hand in hand with multipdp. And I think that the FD wakelock in that case is a good thing. Because it's active with every data transfer, so the phone is already active anyway. But it goes to sleep faster after it's done.

This is especially noticeable with push enabled and transferring lots of little data chunks or keep alives.
[BetterBatteryStats] starkilling:
com.google.android.googlequicksearchbox has been destroying my battery. Does anyone know how I can turn it off?

It doesn't show up in Autostarts.
[BetterBatteryStats] Karpfenhai:
Remove the widget, clear data for this app and on autostarts go to menu show all apps.
[BetterBatteryStats] mikeage:
FYI: Tasker & LocationManagerService

If anyone's using Tasker and sees 100% partial wakelock in LocationManagerService, it's probably related to https://groups.google.com/forum/?fromgroups#!topic/tasker/NP6TbA0fth0 .

FYI.
[BetterBatteryStats] starkilling:
I have no widget running. I cleared data for Google Search. As I said, it doesn't show up in Autostarts.
[BetterBatteryStats] Superm@π:
Will this cause issues with perflock?
[BetterBatteryStats] Karpfenhai:
Here you go!

Tapatalked from my Samsung GT9100
[BetterBatteryStats] starkilling:
Thanks. I couldn't find the exact action, I didn't think to sort by app.
[BetterBatteryStats] Tungstwenty:
More info on sec-battery-monitor, in particular the strange behavior of having huge wake counts assigned to this :)

As mentioned before, the logic of blaming particular KWLs for the wakeup is basically the first one to be activated after deep sleep was activated.

When the power is down, there are registered interrupt routines (ISRs) that can be ran depending on which HW component triggered the wake up.

One example would be the WiFi chip. In that case, the driver's ISR is executed, and within that code the "wlan_wake" KWL will be activated (wc is incremented). After that, pretty much all drivers will be asked to resume the devices they are controlling, and additional KWLs can be activated for a while or not. I'm assuming that sometimes the ISR will also be fired when the device is already awake (to handle an additional incoming packet), which would explain c > wc on that KWL.

WiFi is an example of a device where this works properly.

Another example which is not that consistent is the RTC chip. Alarms are set all the time so that the sleep is interrupted sometime in the near future; when the RTC's interrupt routine is triggered, all it does is reprogram the RTC for the next wake up. After that, it just lets the phone fully awake from deep sleep (the CPU was already awake, but not the devices) and as part of the resume each driver will perform its action in sequence and at some point the action that requested the alarm will do its stuff. Example: the AlarmManager java service can run one of its intents and keep a partial WL (and corresponding KWL) while doing so.

The problem arises in the way that KWLs are aquired in this situation. Apart from the ISR routine which is the first to be executed and might acquire a KWL, after that the drivers are called for resume in a certain order which is always the same. And if some driver (say, the battery monitor) happens to always lock a KWL for a while on every resume, it will look like it was the responsible for the wakeup when in fact it wasn't so.

This is exactly what's going on, at least on an S2 kernel. The battery driver will lock the "sec-battery-monitor" whenever it's resumed, even if the ISR that was fired was for some other driver/device.

And from a quick glance, it appears that only a small part of the drivers do acquire KWLs on their ISRs. The keyboard (physical buttons), for instance, is not one of them. Each wakeup with a power button will be a wake count incremented on the sec-battery-monitor. The same for the RTC (and this one is likely the reason for lots of wc's).

It would be pretty interesting to find out where in the ISR management logic could a detection of deep sleep be inserted, so that it would be possible to create an alternate /proc/interrupts that shows only interrupts that occurred when deep sleep was active, i.e. how many times did each device wake up the system.
[BetterBatteryStats] lordgoata:
@Tungstwenty

Just wanted to say how refreshing it is to have such detailed and informative posts on XDA for a change! Very much enjoyed reading and learning from your posts on this thread, and I echo the suggestions that this information would be really beneficial in the BBS knowledge base.

Thanks again Tungstwenty :)
[BetterBatteryStats] uf21:
Hi, can you please tell me whats causing my to wake up a lot and drain battery. Thanks
[BetterBatteryStats] yhrn:
Thanks again for the info. That confirmed my suspicion about "sec-battery-monitor" and discrete KWLs.

I planned to look into this more but then a lot of other things came up, including the chance to get my I9100 replaced by a I9300. However, before that I got as far as to schedule the following once every hour for 6 hours:

BBS - Dump to file (since custom ref)

BBS - Set custom ref

Dump /proc/interrupts to file

My plan was to write some simple parser that could calculate the delta between two interrupt dumps for a period where BBS showed a lot of "sec-battery-monitor" activity and then post the results here but when I looked at the dumps it turned out that the "Set custom ref" part did not work (will check later if this is a bug in the BBS taske plugin or my own fault) so the KWL section was empty.

In any case, It seems like "sec-battery-monitor" is around on my new phone as well so I'll try to pick this up soon again.
[BetterBatteryStats] lcaveyl:
Hello all,

I need some advice on what is draining my s2 battery after a custom rom upgrade. Attached is my log.

Thanks for any advice or help given.
[BetterBatteryStats] Cucoo:
I'm guessing because of today's Gtalk outage I'm seeing huge partial wakelocks by "GTALK_ASYNC_CONN_com.google.android.gsf.gtalkservice.AndroidEndpoint". IIRC Gtalk is baked pretty deep into Android and you cannot really get rid of, but is there any way to at least get it to stop trying to talk to the mothership? I've signed out of the Gtalk in the Talk app already and disabled all notifications.
[BetterBatteryStats] nobnut:
Number 18 in the Market's New Paid Apps list :)

I'm hoping for more however people. Don't forget a US$1 donation for each app bought will be given to charity by me!

Thank you all and Chamonix.
[BetterBatteryStats] LondonGemini:
Hi all

For a little while now I have been having quite a bit of battery drain. I have attached 2 images. On the first you can see the phone is awake a lot (inbetween the 2 charges) while the screen is off but in the 2nd, better battery is reporting that the number 1 wakelock is only active for 5 minutes?

I can't figure out what's causing this. Can anybody advise as this is getting really annoying.

I should also add that I am using a sgs2 and I don't use latitude.

Thanks
[BetterBatteryStats] bu2askoor:
I think you should have put * since unplugged*.. That would have given a better idea.
[BetterBatteryStats] LondonGemini:
Thanks, I will do that later today.
[BetterBatteryStats] chamonix:
could you please provide the dump from bbs?

from what I see from you wakelocks you have a serious wake problem due to AlarmManager (not the time but the occurences).

I suggest you search this thread for "dumpsys", the analysis of alarms has been wonderfully explained.
[BetterBatteryStats] chamonix:
that IS motivating, thank you guys for making this possible.

hotfix 0.8.4 coming later today (my internet is currently broken) addressing issues #20-22, after that preparation of a mini howto here for release 0.9