[BetterBatteryStats] Tungstwenty:
Hi folks,

I catched up on the thread now and just wanted to drop a quick comment on this issue.

While I don't master all this, here are a few notes that seem logical to me by browsing the sources:

1. wlan_rx_wake

This one is always locked with an associated timeout, and it's either DHD_PACKET_TIMEOUT_MS (1 sec) or DHD_EVENT_TIMEOUT_MS (1.5s).

From the names and the behavior, I'm guessing this lock is probably acquired *after* a certain packet has be received (or sent ???) and there's a time frame during which the "rest" of the stuff should happen - the router consuming the packet (or event) and acknowledging it, etc.

From a quick glance at my current stats (not a lot of wifi usage, though), its WC is 0 and the EC is exactly the same as C - every single lock was unlocked by timeout.

2. wlan_wake

This is locked/unlocked explicitly, and indeed some of the time it will produce WCs. This means this is the first KWL acquired after the device woke from deep sleep, and it seems to be one of the indicators that an inbound WiFi packet has caused the interrupt routine for the device to wake the phone.

I'm recalling one of the features mentioned in Siyah which is the multicast being disabled, in order not to wake the device. I'm assuming that it's the controller that is programmed not to bother with inbound packets (all points that way). But on a weaker implementation or a not-so-good controller, it's conceivable that the interrupt routine would still fire every time but ignore the unwanted packets at that level, instead of proceeding to a full wakeup. If that was the case, the device would still be waking up on a dirty network, you'd just not see it in the KWL indicators.

Some ideas of ways to monitor dirty network behavior:

- Checking WC of "wlan_wake"

It will only catch situations where the device was in deep sleep, and the WiFi driver is properly being the first one to acquire the KWL upon interrupt. I mentioned before that the battery monitor KWL has an odd behavior with regards to this, but at least on my S2 it's the WiFi one that "wins" when the wakeup was caused by an incoming packet.

- As a complement to the KWLs, also monitor the interrupts

On /proc/interrupts and /proc/softirqs you can also find interesting counters related with WiFi, namely the number of times the ISR was called to handle an incoming packet. And, as a bonus (depending on what you want to measure), it will report everything irrespective of whether the device was asleep and woke up for that, or if it was already awake.

cat "/proc/interrupts" shows this for me:

CPU0
20: 13782 s3c-uart
22: 8227 s3c-uart
98: 0 GIC s3c-pl330.0
...
[COLOR="Red"]373: 22951 exynos-eint bcmsdh_sdmmc[/COLOR]
...

The red line shows the relevant entry, but this is only for the S2. For your device you'll need to check which entry is the one.

You can "ping" your phone from a computer to control regular packets being sent, in order to see the number increasing in a controlled way.

In my case, perhaps due to Siyah, it's more or less stopped (apart from small increments every now and then that might be for channel syncing with the router). When I start pinging from the PC, it will increment by 1 for each second.

Opening a browser or similar will skyrocket the value, obviously.

The other thing that can also be checked is "cat /proc/softirqs":

CPU0 CPU1
HI: 462 0
TIMER: 2042216 435542
NET_TX: 29998 1
[COLOR="red"] NET_RX: 68388 427[/COLOR]
BLOCK: 462 0
BLOCK_IOPOLL: 462 0
TASKLET: 665132 60
SCHED: 108821 118565
HRTIMER: 12514 911
RCU: 646876 427705

The behavior seems to be identical.

The fact that the numbers are way off is likely the fact that when WiFi is disabled, the interrupts value goes away (the driver is unloaded) but the NET_RX softirq does not. When WiFi is turned back on, the interrupt count starts at 0 but not the softirq.

I hope this can help make some sense of the received garbage from WiFi networks:

a) pretty much everything on NET_RX or the appropriate interrupt, if everything is idle (irrespective of whether the device was awake or asleep)

b) the WC value of wlan_wake, for only the situations where the device was asleep (provided there's no confusion in the driver ordering, like the battery monitor one ...)

Cheers!

---------- Post added at 04:03 PM ---------- Previous post was at 03:27 PM ----------

Sorry for the late reply.

I'm glad you managed to do some progress and get at least part of it working.

I don't know what could be wrong for you not to have data in the stats, so here are a few things you could try out:

- On my device, /proc/net is a symlink to /proc/self/net (replacing self by the pid of the shell). Could you try going to some other process and try it there? Example: "cat /proc/1/net/xt_qtaguid/stats"

- Any info on the "ctrl" file?

- Does your kernel include ipfilters built-in, or at least compiled as a module and then loaded? "iptables -L" should show you some rules. I don't know if that's the best way to check if ipfilters is running/loaded.

About the xt_socket.c/h files, I compared on kernel.org the latest versions of 2.6.* and 3.0.* and they have just 1 or 2 lines of difference. Comparing 2.6.* with the 2.6.37 you mention, there are some differences but it looks like only related with ipv6 support.

As chamonix mentioned, if there are no lines reported on the stats file, then there's no info to report :(