Battery Drain Results

---

Hi

I noticed I was getting larger battery drains at work than at home whilst using wifi, this coupled with the fact i am having large wlan_rx_wakes and wlan_wakes leads me to believe that the works router is the culprit (which I unfortunately have no access to in terms of changing network settings).

I have managed to get about an hour of testing (unfortunately it was towards the end of the working day) from Betterbatterystats, Shark and CPU Spy to show. I am just wondering if anyone can identify any other problems I may be able to solve from these results.

If the length of time is too short then I can run a test tomorrow as well

NB. IF its of any use I tried using JuiceDefender during work and it gives me noticable improvements in battery life with no wlan_rx_wake or wlan_wake.

CPU Spy results:

Total State Time: 1:09:06

Deep Sleep 0:36:69 52%
200 MHz 0:14:42 12%
300 MHz 0:01:16 1%
400 MHz 0:00:42 1%
500 MHz 0:03:22 4%
800 MHz 0:10:18 14%
1000 MHz 0:01:49 2%

Originally Posted by burgess_boy

Hi

I noticed I was getting larger battery drains at work than at home whilst using wifi, this coupled with the fact i am having large wlan_rx_wakes and wlan_wakes leads me to believe that the works router is the culprit (which I unfortunately have no access to in terms of changing network settings).

GAAHHH! KILL IT WITH FIRE! Your work network sucks. No further capture required. I've never seen a capture as busy with broadcast and multicast yuckiness. I don't think I've ever seen Wellfleet BOFL PDU's in a capture before. There is quite a bit of IPv6 chatter as well. All in all it does not look like a good network to connect to if running on battery.

Originally Posted by elherr

GAAHHH! KILL IT WITH FIRE! Your work network sucks. No further capture required. I've never seen a capture as busy with broadcast and multicast yuckiness. I don't think I've ever seen Wellfleet BOFL PDU's in a capture before. There is quite a bit of IPv6 chatter as well. All in all it does not look like a good network to connect to if running on battery.

Thank you very much for the response. I had my suspicions as im losing between 8-12% of battery an hour. Think I'll be using mobile data from now on

Sent from my GT-I9100 using XDA

Originally Posted by burgess_boy

Thank you very much for the response. I had my suspicions as im losing between 8-12% of battery an hour. Think I'll be using mobile data from now on

Thank you. Now I have an example of a truly ugly wireless network. I'm still learning a great deal about the Android IP stack (and Android in general), but it appears that Linux netfilter is implemented in Android (well CM9 anyway...) as well as userspace tools. If rules are implemented at the interface (BCM4330 hardware/firmware), then one could build rules to filter unwanted traffic. I can't think of any reason for a phone to listen to IPv4 multicast (224.0.0.0/4), STP (01:80:C2:00:00:00), etc. In most situations one could ****can IPv6 in its entirety.

CM9 appears to pass everything by default.

shell@android:/ # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
           all  --  anywhere             anywhere             ! quota globalAlert: 2097152 bytes 
ACCEPT     all  --  anywhere             anywhere            
           all  --  anywhere             anywhere             owner socket exists

Chain FORWARD (policy DROP)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
           all  --  anywhere             anywhere             ! quota globalAlert: 2097152 bytes 
ACCEPT     all  --  anywhere             anywhere            
           all  --  anywhere             anywhere             owner socket exists

Chain costly_shared (0 references)
target     prot opt source               destination         
penalty_box  all  --  anywhere             anywhere            
           all  --  anywhere             anywhere             owner socket exists
ACCEPT     all  --  anywhere             anywhere            

Chain penalty_box (1 references)
target     prot opt source               destination

More to play with. Fun! I seem to be spending most of my time in ADB shell these days... :)

Originally Posted by elherr

GAAHHH! KILL IT WITH FIRE! Your work network sucks. No further capture required. I've never seen a capture as busy with broadcast and multicast yuckiness. I don't think I've ever seen Wellfleet BOFL PDU's in a capture before. There is quite a bit of IPv6 chatter as well. All in all it does not look like a good network to connect to if running on battery.

Hi elherr, you are a great deal here to help us on network side.as I previously posted many times, my case is similar to that of burgess_boy! So, are these work wifi's ( which we don't have any control over at work..use it or loose it policy!) misconfigured or configured correctly for some... some... reasons such as security probes or anything . Throw us some ideas what we can go and tell network engineers at work..or how we can show them this problem on our phone while phone's connected on wifi and adb@adndroid#

makes sense?

thanks!

Guys multipdp and wlan rx and mail app (exchange polling every 15 mins, sync disabled to try and reduce this problem) are killing me with wake lock time and count.
I already disabled IPv6 on every networked PC and on my phone, and turned off dhcp (that god rid of the dhcp wake lock it seems...).
Any other suggestion? How to track which app is connecting so often and giving problems? I already ditched Facebook for friend caster..
Thanks a lot!

Sent from my SGS2 - SlimICS Rom & Fluxi Kernel

Originally Posted by rav4kar

Hi elherr, you are a great deal here to help us on network side.as I previously posted many times, my case is similar to that of burgess_boy! So, are these work wifi's ( which we don't have any control over at work..use it or loose it policy!) misconfigured or configured correctly for some... some... reasons such as security probes or anything . Throw us some ideas what we can go and tell network engineers at work..or how we can show them this problem on our phone while phone's connected on wifi and adb@adndroid#

*** Using a packet sniffer (e.g., Shark for Root) on a company network is typically frowned upon. Frowned upon as in: You-Have-Been-Sniffing-My-Network-WIth-A-Rooted-Device--I-WILL-KILL-YOU-NOW! ***
Having said that, you can run Shark and look for chatty broadcast/multicast in your capture. Unfortunately, a good portion of that traffic may be required by other hosts (computers) for normal operations, so it cannot be blocked on the network. There are too many variations in network design to say for certain.

What may work out is developing netfilter (iptables in userspace) rules to block some of the traffic at the phone interface. I have not played with this yet. If we can block traffic at the WLAN interface all is good. If the traffic has to be processed by the kernel then the exercise would be pointless, as that would mean you would still be generating wakelock just to have the kernel drop the packet.

As I've said before, I'm still learning how Android works, so take what I am saying with a grain of salt -- aside from the sniffer warning at the beginning. If you want to see a network admin develop cloven hooves, a forked tail, and glowing eyes, tell him you've been running a sniffer on his network.

Originally Posted by cyberpunk627

Guys multipdp and wlan rx and mail app (exchange polling every 15 mins, sync disabled to try and reduce this problem) are killing me with wake lock time and count.
I already disabled IPv6 on every networked PC and on my phone, and turned off dhcp (that god rid of the dhcp wake lock it seems...).
Any other suggestion? How to track which app is connecting so often and giving problems? I already ditched Facebook for friend caster..
Thanks a lot!

I have my domain hosted on Google and am syncing all services (Blogger, Browser, Calendar, Chrome Beta, Contacts, Currents, Drive, Mail, Photos, G+, etc). I also have Exchange ActiveSync Contacts, Mail, & Calendar active. On wifi I'm getting about 90% deep sleep during idle times. Obviously, when I have a truckload of email hitting my inbox this percentage declines. I'm pretty happy with this figure.

One thing that I did notice that was causing more wakes on wifi was what appeared to be Google location service scanning for nearby access points. I disabled Google location service and significantly improved sleep times. This was on CM9 0519.

DHCP should not cause issues unless the lease time is insanely short. I've set my lease time to two hours with WPA2 TKIP group rekey set to 10 minutes.

On HSDPA or 3G, my sleep time is running at 75% give or take. secril_fmt-interface and l2_hsic wakelock seem to be a couple of the top talkers. From what I am reading, 'secril_fmt-interface' is part of the Radio Interface Layer (RIL), and l2_hsic is (guessing here...) Layer 2 HSIC (High Speed Inter-Chip). HSIC is a variation on USB and is used by CPU to talk to various peripheral devices, including the phone's baseband... Bah! Learning Android is like drinking from the proverbial firehose.

If you have Shark for root installed, capture WLAN traffic during an idle period. See post #1 for instructions. I'd be happy to take a look at the capture.

Cheers,
Edward

Argh! Boo, hiss. I finally got around to adding rules and it looks like, as I feared, netfilter rules are entirely processed in the kernel. wlan_rx_wake is incrementing even though packets are being dropped. This is quite sad considering the BCM4330 has an embedded ARM processor. One would think that it would easily be able to filter traffic on chip.

Possibly there is another mechanism for pushing filters to BCM chip but I have not found one so far.

Looking at dials and switches exported via sysfs -- does not look pretty.

I've found two things now that I really miss from Linux: lsof socket support and wireless tools (iwconfig, iwlist, iwpriv, iwevent, etc).

Originally Posted by elherr

Argh! Boo, hiss. I finally got around to adding rules and it looks like, as I feared, netfilter rules are entirely processed in the kernel. wlan_rx_wake is incrementing even though packets are being dropped. This is quite sad considering the BCM4330 has an embedded ARM processor. One would think that it would easily be able to filter traffic on chip.

Possibly there is another mechanism for pushing filters to BCM chip but I have not found one so far.

Looking at dials and switches exported via sysfs -- does not look pretty.

I've found two things now that I really miss from Linux: lsof socket support and wireless tools (iwconfig, iwlist, iwpriv, iwevent, etc).

It does install filters, look in:

/kernel/samsung/smdk4210/drivers/net/wireless/bcmdhd/src/dhd/sys/dhd_linux.c

You'll see dhd_set_packet_filter() installs the packet filter if dhcp is not in progress.

If you follow the code in there you can see filters get turned on and off depending on suspend state.

In, fact using the wpa_cli tool (in /system/bin) you can manually set the filters by using the wpa_cli 'driver' command. So....

If you want to compile your own kernel and add some trace output each time the filters are installed/uninstalled (in the suspend functions in dhd_linux.c) you can see if the filters are in place when each suspend happens.

You will then be able to see these messages in dmesg and confirm that the multicast filters are enabled when the device suspends.

Originally Posted by othermark

It does install filters, look in:

/kernel/samsung/smdk4210/drivers/net/wireless/bcmdhd/src/dhd/sys/dhd_linux.c

You'll see dhd_set_packet_filter() installs the packet filter if dhcp is not in progress.

If you follow the code in there you can see filters get turned on and off depending on suspend state.

In, fact using the wpa_cli tool (in /system/bin) you can manually set the filters by using the wpa_cli 'driver' command. So....

If you want to compile your own kernel and add some trace output each time the filters are installed/uninstalled (in the suspend functions in dhd_linux.c) you can see if the filters are in place when each suspend happens.

You will then be able to see these messages in dmesg and confirm that the multicast filters are enabled when the device suspends.

I pulled smdk4210 kernel from github and am looking at the source. Since filters appear to only be pushed to BCM4330 during suspend it makes testing less than straightforward. Adding trace output might tell you that driver reports filters have been applied but is not proof-in-the-pudding.

Next week (fairly busy this weekend) I'm going to set up a test network and use one of my Linux boxes to simulate a dirty network. I'll try testing with various filter rules on and off and see what impact filters have while phone is suspended

Thanks again. I had not started looking at kernel code as yet.

Edit: This looks like something one could create some havoc with.
http://packeth.sourceforge.net/