[Galaxy S II General] Entropy512:
And in those two weeks, I've run more controlled tests (Top off battery, reset CPUSpy timers, then let it drain in known signal conditions, approx. one every night) than I have seen from you (0 controlled tests - just a bunch of flailing about with no methodology and poor data collection practices, we'll get to that later.)

I took a while to reply because I wanted to collect more data. Signal strength matters for battery life in a cell phone - over a decade of owning cell phones of various technologies, and battery life being negatively affected for poor signal strength has been a universal truth on all of them. It matters less so for GSM/EDGE (due to them using timeslots for multiple channel access, which necessitates less aggressive transmit power control.) than for CDMA-based technologies (cdmaOne, CDMA2000, UMTS) which have strict requirements on handset transmitter power control to solve the near/far problem. UMTS has been notorious for high battery drain since its inception, which is why people STILL like to try and force GSM/EDGE mode on modern phones. The situation has improved a lot since the early days of UMTS, but we've been at the physical limits of transmit power amplifier efficiency for a while. You seem to have ridiculous expectations that compared to recent predecessors, the GS2 is some sort of mythical god-phone that can violate basic laws of physics, such as conservation of energy. Sorry, it isn't - just like any other phone, the radio is bound by the laws of physics.

You asked me what my usage patterns were that I would consider less than 1%/hour idle drain to be good, since you think that should be bad.

1) I'm in the United States. Population density is lower, which means tower density is lower, which means signal strengths on average are much lower than is likely typical in Europe.

2) I'm on AT&T. There's no conclusive evidence that the network supports fast dormancy, but most anecdotal evidence indicates that it does not, despite AT&T labs having an article that talks about it (although it also talks about how AT&T is, as usual, working on their own way of doing things. AT&T is a major sufferer "not invented here" syndrome). (Enabling fast dormancy on the Infuse caused all sorts of problems, enabling it on the GS2 does nothing, so at least the GS2 has saner fallback with enabling it on a non-supporting network.) Fast dormancy is a known battery-saving feature.

3) I'm on AT&T - There's enough known about their network that it's obvious they're one of the "big two" in this poorly anonymized paper, and the rash of recent people getting tethering nastygrams makes it obvious they're the carrier doing DPI - http://research.microsoft.com/en-us/people/mzh/netpiculet.pdf - Unfortunately NetPiculet is no longer available, but I'd be shocked if AT&T is not one of the carriers with ridiculously low TCP timeouts, also known for causing poor drain.

Unfortunately I'm a bit short on weak-signal tests due to a persistent sinus infection - I've missed a lot of work (which is my classic weak-signal test case) in the past two weeks, but on the data runs I've taken, the pattern is consistent - poor signal has a significant detrimental affect on battery life, both because the radio has to work harder, and also deep sleep percentages start dropping as sync processes hold wakelocks longer.

BTW, I've never seen events/0 or suspend take more than a minute out of a 12-hour run, even on .7 kernels. Yet AOS is claimed to have 40-60% usage in a situation where drain performance is excellent. The AOS reported usage is just plain inconsistent with reality.

Resorting to profanity now, are we? A clear sign you know your arguments are falling apart.

I've been working as an engineer long enough to know not to blindly accept marketing material as truth. "claims" power consumption "nearly half" in marketing material - what's reality? Anyway, you can reduce CPU usage all you want, as I said above, all that will do is make signal strength dominate even more.

Not a 2 year gap - the S5PV210 in the Infuse is a refined variant of what most first-gen GalaxyS phones had, and hence includes most of those yield and process improvements (which is why it's sold at 1.2 GHz instead of 800 or 1.0, and reliably hits 1.6 for more people than previous chips). It's architecturally midway between the original GS and the GS2 - for example, it has the exact same wifi chip as the GS2, and probably the same baseband. Anyway the baseband doesn't matter, even if the baseband consumed no power, see my previous comments regarding the RF power amp.

More profanity, huh? Especially amusing considering that the link you gave me confirmed my claims, it's pulling current numbers out of its ass. If it isn't measured directly with a current sensor circuit, it's worthless. So please stop talking about current draw until you start using a method that actually makes sense and provides valid data. (Either a backport of the MAX17042 current sensor support from the Linux 3.1 kernel trees, or replacing the device battery with a dummy battery that includes a current sensor, connected to an external battery)

And yet again, you provide excellent evidence that you don't know what you're talking about. The fuel gauge isn't used? Where the hell do you think the state of charge estimates come from? Thin air?

Nope, they come from here:

/sys/class/power_supply/battery/batt_soc

If you actually bother to read the code, you'll see where this comes from - the MAX17042. While the 42 supports some additional features not present in the 17040, those features aren't used in our device. But the fuel gauge IS there and IS used.

Did that last night. I'll attach the results as a .zip because individual images is a pain in the ass - nothing unusual, no major unusual wakelocking, although the battery monitor wakelock is a bit higher than I'd like, that's because AT&T apparently wants it polled at 10 seconds instead of 40. AT&T is kind of notorious for doing things that break battery performance...

More profanity - and more evidence that you don't have any proper debugging methodology. You claim it's a huge kernel bug, without a single direct kernel artifact. In the entirety of this thread, you have not posted a single dmesg, nor have you posted a single /proc/wakelocks dump. All you've done is blindly trust screenshots of your point-click-drool apps. More on this soon.

Because the people in this world that piss me off the most are those that try to pass themselves off as experts, even though their data collection techniques are piss-poor and they clearly know less than they're representing themselves as knowing.

In your case, your findings and debugging have collected data from:

1) An app (Battery Monitor Widget) that is clearly marked by its author as providing inaccurate data on our device

2) An app (BetterBatteryStats) that doesn't show all wakelocks in the system - yet you claim there's a kernel bug because you trusted the app instead of looking at /proc/wakelocks. See the ODF spreadsheet in bln_wakelocks.zip, which is derived from a /proc/wakelocks dump of the one case where I've had severe battery drain caused by a kernel bug (as we said in the Infuse community - ****ing BLN...) but calculates human-readable values for the total time and sleep (screen-off) wakelock time. In this particular controlled test (enable BLN, enable the "test notification", turn the screen off for a good long time), BLN held a wakelock for 60 minutes. Yet BetterBatteryStats didn't show a thing.

3) A system app (Settings->About Phone->Battery Usage) that is known to have bugs (such as displaying 100% time with no signal when that clearly isn't the case) - so why do you trust it?

Your data collection has not included, in the entirety of this thread:

1) A single dmesg dump

2) A single dump of /proc/wakelocks

Yet you claim definitively there's a kernel bug, despite not having a shred of evidence that is directly derived from the kernel?

So now someone from Samsung may be watching this thread, which poorly represents XDA as a bunch of idiots who do "boy who cries wolf" with no proper data collection methodology. It'll make it harder to have them pay attention when there are real problems with properly collected data to back it up.

p.s., if SamsungJohn is still following this thread:

1) MAX17042 datasheet please? We had it for the MAX17040 functionality inside the MAX8998 in the GalaxyS/Infuse, and it looks like it was available at one point for the 17042 within the MAX8997 of the I9100/I777, but it doesn't seem to be there any more.

2) I know this is far less likely, but MAX8997/8998 datasheets please?

3) Even less likely, Exynos 4210 datasheets, or at least better documentation of clock divider registers and clocking architecture. We've got leaks of the S5PC110 which seem to translate well to the S5PV210 in those regards, but it's clear there's a lot of new clocking stuff in the Exynos 4210 - I realize why you wouldn't want to support/condone overclocking, but people are doing it, and since they are, why not make sure they're doing it armed with proper information on what is what?

4) Why does the Infuse count CPU/screen usage against battery charge current limits? This leads to battery drain when running navigation on a charger at full brightness (confirmed behavior), and also potentially may lead to improper battery charge termination, potentially damaging the battery (not confirmed, there may be charge cutoff safeguards beyond the check_chg_current loop in the kernel). PM me for more details and my test methodology if you want, it's a bit offtopic for this thread. This behavior also seems to be present in the I9100 and the I777, although at least with the I777 there's more evidence of safeguards beyond the cutoff loop in the kernel. I don't have enough data on these devices to call "Problem/bug!" though. Also I'm in the process of trying to get data from I9000s and Captivates, the kernel code and what I know of the MAX8998 from the kernel code say they should have the same problem, but user anecdotes indicate something seems different and at least the Cappy charges much faster stock, which is odd since its current limits are the same and battery is only slightly smaller.