[Galaxy S II General] AndreiLux:
I am not arguing with you on cell phone signal strength, and I never have. This is the 3rd time now that you are throwing me a cell phone radio power usage lecture onto me when I have told you that this issue is not about that. This thread is not about discussing battery life in general but about discussing one issue out of many which is causing detrimental battery life. And as for my "great" signal reception (83dBm, 18asu; 97-103dBm on 3G), it doesn't matter because every focus testing I've been doing was at home using 2G, in the same locaiton/romm, under the same Wifi. Of course if I wander through the city the battery drain rightfully will be unpredictable and high.

Again, this is worthless. More on this later on.

The very first thing you've been telling me ever since that thread in the AT&T forums is that I'm talking out of my ass, calling me clueless and telling everybody that I'm just spreading nonsense, and that was over a week ago. If you're calling my use of "****ing" profane over the way you're portraying me and been talking to me as if I was some child, and then dare to critique me now because of that as if and you're now somehow offended, or because you think I'm cornered in? This is just my way of being uncivil with you as you are with me. I'm sorry if I'm not as eloquent as you by not telling you that you are the one talking out of your ass as the very first thing, maybe because English is not my first language, but if you want me to I'd also argue with you in 4 other tongues.

I was merely pointing out that you cannot compare this device to the Infuse as you've been doing it for every single post now when discussing the issue. I do not care if those marketing claims of 50% improvement are real or not, my point was simply that the architectures are vastly different from each other and cannot simply be compared one to another, something you've been doing all along now. I do not know what the real statistics are, and neither do you, so stop saying it's "similar with just another core added in" because that is not reality.

This is getting ridiculous. I've been stating from the very first beginning since I've mentioned mA draw that Battery Monitor is merely an estimate and not real-world measurements. The only reason I've even mentioned and talked about it was because another poster posted his screencap of usages. And it is not worthless as even as inaccurate and non-representative of the real-world it is, it is a good estimation because it damn works. A doubling of mA draw shown there, will actually be correlated to a halving of the time it takes to drain a single percent. Also the only reason I argued about battery calibration because the poster deleted his batterystats.bin before testing, and it's known as a fact that during the first few charges of an uncalibrated battery the OS doesn't know what a full charge is and can show 100% while the battery in reality is at 96% and therefor, as we've seen it time and time again, people falsely report they've been running for phone for 3-4 hours and it's still at 100%. All you did was throw me another unnecessary lecture on fuel gauges since you simply took it out of context and jumped on the conclusion I don't know what I'm talking about.

As I've said even if BMW is incorrect in absolute mA usage reports, it does not matter because what we're measuring is relative drain to the same device itself and that it is more than accurate enough as I've said before. And even if you don't care about those numbers you can still use it as a logging programm to monitor percentages and deduct drain from %/h if you want to be anal about correct data collection methods.

That's an issue with the modem, which doesn't behave that way anymore if you flash a version >KI3 (Modem only, nothing else). Aren't you reaching a bit far now as to now calling the Battery Usage screen inaccurate and false? The graph is correct, the per app percentages ARE correct (more on that later) as far as to this issue at hand now.

I did not pass myself as an expert nor did I say that I was sure of the issue as I've just posted my findings, reasonings, and arguments, and now up until you came, nobody has argued it wrongly or actually been able to disprove any of the things I've said. To the contrary, with people sharing the same observations.

I'd love to work in a company where their consumers do all the work for them, wouldn't you? Why not go a step further and tell them exactly which parts of the code are wrong and how they should write it? Do you even step back for a moment and think about what you're expecting and demanding?

Fact is this thread and the summarization I've written on the issue, and which 80% of the users who actually have the issue agree with and can replicate, is the single best thing we have right now on the topic, and they're been a dozen big threads about this issue all over the place and all I've did was collect it all and tied it to the biggest common denominator everybody has been experiencing. Also don't blame me for making the front-page as I wasn't even aware of it until the day after, and that editor is clearly clueless as he didn't even mention the context of the whole situation.

You better send SamsungJohn those questions per PM.

Actually I'm fairly certain that's not true, there's already a guy in this very thread reporting the same issues (and many more added on top), and I've seen enough of them in the ATT forums. Basically the AT&T General forum right now looks what ours looked like 3 to 4 months ago in terms of theories on bugs, battery drain, and whatever else is popping up out there.

Now...

For the data.

I must admit that I haven't kept detailed raw wakelock data as I've been lazy and just been using BBS. You can flame me on that indeed. Therefor I'm doing again a new data collecting to match yours. (Airplane mode, Wifi). Already in 8 minutes you can see this:

​

So I've already had 1648 wakelocks from the Wifi inside of 8 minutes of uptime compared to your 2100ish inside of 9.5 hours of the data you've posted. Again, the cpu states show exactly what I've been talking about, and I also switched to the stock KI3 kernel to be able to show you the high suspend and events/0 usage:

​

Edit: I ****ed up the CPU state screenshot, that's a previous one, sorry. But the percentages looked exactly the same, just for a 8 minute period.

Again, this was in 8m30 uptime, 3m40s of those awake, 40s screen on time. The dump is done about 10 seconds before the screenshots.

As you can see in the dmesg it enters sleep 22 times in exactly about 44 seconds, with sometimes 1-second interval, and as you've said it takes a while to enter and leave sleep, both of which add to about roughly 1s. If this isn't sign of an infinite enter-sleep-wakeup-instantly behavior, then I don't know. dmesg is already trunkating itself inside of 1 minute, so I'll have to ask you how you managed to get a 8 minute 500kB dump as mine are all ~128kB...

It looks ridiculously to what I've been talking about since the very beginning as to it's maybe an issue as on the Galaxy S with the Wifi drivers. I've got a ton of other screenshots and dmseg logs but I'm doing another log capture tonight to have the same relative relevance between the data as in your testing.

I'll post tomorrow the log over the period over the whole night, and the day after that one with a recent .14 kernel. [Actually most of the dmesgs attached are on .14]