[BetterBatteryStats] Tungstwenty:
Thanks a lot for the info and links, pretty interesting read :)

Considering that (at least on my S2) it takes about 1.5s to fully enter deep sleep and 1.6-1.7s to resume, it's pretty relevant having so many transitions that are possibly not (completely) accounted for.

<6>[22183.074440] PM: suspend of devices complete after 137.020 msecs
<6>[22183.083202] PM: late suspend of devices complete after 1.300 msecs
<6>[22183.084741] PM: early resume of devices complete after 1.285 msecs
<6>[22183.575037] PM: resume of devices complete after 490.022 msecs
<6>[22185.159443] PM: suspend of devices complete after 137.010 msecs
<6>[22185.168227] PM: late suspend of devices complete after 1.293 msecs
<6>[22185.169765] PM: early resume of devices complete after 1.285 msecs
<6>[22185.661095] PM: resume of devices complete after 491.055 msecs
<6>[22187.014450] PM: suspend of devices complete after 137.037 msecs
<6>[22187.023185] PM: late suspend of devices complete after 1.279 msecs
<6>[22187.024721] PM: early resume of devices complete after 1.287 msecs
<6>[22187.506275] PM: resume of devices complete after 481.279 msecs
<6>[22219.760037] PM: resume of devices complete after 328.614 msecs
<6>[22225.819521] PM: suspend of devices complete after 137.090 msecs
<6>[22225.828305] PM: late suspend of devices complete after 1.293 msecs
<6>[22225.829969] PM: early resume of devices complete after 1.286 msecs
<6>[22226.295245] PM: resume of devices complete after 465.005 msecs
<6>[22246.229473] PM: suspend of devices complete after 187.001 msecs
<6>[22246.238254] PM: late suspend of devices complete after 1.317 msecs
<6>[22246.239801] PM: early resume of devices complete after 1.286 msecs
<6>[22246.727085] PM: resume of devices complete after 487.010 msecs

Perhaps it would be useful to see some set of counters that would show how many power transitions occured.

An easy way would be to have a sum of all the KWLs' WCs, but there could be situations (especially these frequent wakeups) where a driver IRQ fires up but doesn't fully power on the device by means of the acquisition of a KWL.

The stats of the cpu, under "/sys/devices/system/cpu/cpu0/cpufreq/stats", are typically not compiled on a kernel to include the transitions between states (which perhaps includes the stopped<->freqX) but only a total_trans with a global counter of changes between frequencies. I'm not even sure whether deep sleep is also considered. Plus, cpuidle (even without deep sleep) might also enter those counters but not be relevant for deep sleep measurement. After all, there's no entry in "time_for_state" for the *zero* frequency...

Another thing that I don't completely understand is the level of sleep / wake involved in reacting to an interrupt such as a wifi packet. Even if the response is very lightweight, at least the CPU and a few devices must be powered up and then sent back to sleep. But to what degree? :confused:

Something to investigate whenever I have some spare time...

EDIT:

Something else I wanted to mention.

From what I read in the sources, there are rx_wake timeouts for "...PACKET..." and for "...EVENT...". Perhaps events have something to do with "non-packet" packets exchanged with the router? Probably not ICMP or IGMP, but other low level signalling that might be used for maintaining the radio interface established in order to carry the packets(?)

Anyway, the stuff you mention is clearly related to actual packets, just not the usual TCP-UDP / IP ones.