Shibby N5x drains mobile power, AC6x doesn't

Discussion in 'Tomato Firmware' started by GetOperational, Dec 21, 2013.

  1. GetOperational

    GetOperational Networkin' Nut Member

    tl;dr version: Newer Tomato Shibby N5x firmwares can cause dramatically higher power consumption on mobile devices than AC6x firmwares. This can happen just by being connected to the router and idling.

    I spent a few hours figuring this out yesterday, perhaps this is already a known issue but I thought I would post it in the event it could be of use to someone.

    Asus RT-N66U
    2ghz/5ghz wifi: both using "n only", wpa2 personal, aes

    Nexus 5 running stock android 4.4.2 with no background programs running.
    Wireless chip is a Broadcom BCM4339

    Had been running with this firmware for months with no problem.

    Upgraded to this firmware (did nvram clear at installation) and mobile battery use shot up. The total power consumption for the device sitting on a table with the screen off jumped from 0.8%/hour to 5.5%/hour after installing this firmware.

    Switched to this firmware and battery use went back down to 0.8%/hour.

    (things I tried that no effect)
    Changing between the 2ghz and 5ghz access points.
    Clearing all of the saved access points from the phone, putting phone in airplane mode, rebooting phone, changing the phone's wifi scanning settings.
    Creating new access point names/passwords on the router, changing channels, clearing nvram and manually entering settings, static vs random dhcp assignment.

    Also while this was happening the phone was not transmitting data (I disabled syncing for the test) it was merely connected to the AP.
    The device shows no unusual wakelocks, there is no program in the background waking the device up.
    The only service that showed higher than normal power consumption was the Android "WiFi" process.

    (what it could have been)
    I had read that some were able to solve similar problems by messing with "Beacon Interval" or "DTIM Interval". Possibly due to a beacon timing issue preventing the phone from from entering deep sleep in-between intervals. I did not touch any of these settings and left them on default.
    I had also read that the AC6x firmwares used a newer driver for the radios so perhaps that was what made the difference. I still don't know for sure if this was a Tomato bug, a Broadcom bug, or an Android bug. In any event everything seems to be working now.
  2. mstombs

    mstombs Network Guru Member

    Interesting, thanks I also suffer occasionally from high battery drain on Android due to Wifi - I have suspected it is broadcast messages which prevent the phone from sleeping, but also I have never found a firmware for my phone that roams correctly between access points of the same name - staying connected to a weak AP gives lousy throughput/ battery drain (fix by turning wifi off and on again). Good to know that newer router drivers are a step in right direction!
  3. GetOperational

    GetOperational Networkin' Nut Member

    I am more of a server guy than a radio guy so much of this seems like a black art to me. The more I read about wifi/cellular the more I realize there is a lot more complexity there than I initially thought and I really don't know anything.

    There are a lot of discussions online where a group of people will be talking about a particular mobile device and some will claim to get great battery life while others report a very difference experience. From what I have seen this is typically due to wakelocks, usually some programs running in the background transferring data periodically and waking up the device. But I am starting to wonder if some percentage of those people with bad battery life might be running into wifi ap issues like this.
    In my example the difference between the two router firmwares is huge, over the course of a workday idle power drain could be <10% for one and 50% for another.

    One more data point, at work I roam between a dozen or so different Cisco Aeronet access points of various ages and have not experienced the drain issue there.
    Last edited: Dec 21, 2013
  4. Toastman

    Toastman Super Moderator Staff Member Member

    When it comes to Mobile devices, esp. Android, one of the things that really annoys me is the fact that apps are not terminated when you finish with them. I have a 4 core processor which is initially fast and impressive but as the day progresses the damned thing becomes as slow as a turtle with a broken leg, sometimes almost to the point of being unusable. Despite the ridiculous claims from Android team that the phone will manage apps and memory to keep it running smoothly, in practice this is utter baloney.

    Battery drain on wifi is badly affected by what mstombs has noticed, android devices mostly don't connect to, or roam, to the strongest access point. In fact, most wifi clients are bad at it these days, but we don't worry so much with laptops because they have bigger batteries. Battery drain is also affected by the setting of the client and/or router's power management features. Switch it on, you get battery savings but poor performance and dropped packets, switch it off, and you get higher drain.

    3G used with a low strength signal is a HUGE drain on battery also, as I found out recently on a 4 day trip to the country.
    kthaddock likes this.
  5. lancethepants

    lancethepants Network Guru Member

    Ha, made me chuckle.
  6. PhilLee

    PhilLee Reformed Router Member


    Found this thread while researching a similar issue with a Billion 7800DXL router and my Nexus 5 using more battery power at home than at work on Wi-Fi.

    After lots of troubleshooting I found the issue was with the Beacon Interval. At home I had changed this to 250 from the default 100, which should help mobile devices save power as they can sleep a bit longer between beacons.

    The Nexus 5 and BCM4339 seems to have an issue with thes Beacon Interval at anything higher than around 150 and so appears to drop of the Wi-Fi network intermittently when in sleep mode. This can be seen sometimes on turning the phone on and then bringing down the quick settings menu and seeing the orange Wi-Fi icon to show connection was lost with Google services.

    This causes extra power drain for a few reasons, one the constant disconnection to Google services means more wake-ups are scheduled to reconnect back, and I suspect the phone is also reconnecting to the cell data network then back to Wi-Fi again. The Nexus 5 was showing 5 times the number of wake-ups by Google services than a Nexus 4. Reducing the Beacon Interval down to 150 and the battery drain is gone and connection is maintained.

    Perhaps the differences between the firmwares is the default Beacon Interval causing a similar issue?

    A Nexus 4 and 7 are all fine on the higher Beacon Interval.

    Of course at work I'm pretty sure the Beacon Interval is at the default of 100.

    I have to disagree with this. Applications are terminated and stop running, unless the application has been designed to continue in the background. What happens is while the application thread is halted so no CPU cycles are used by that app, the application is still maintained in memory, and can be switched back to and started up again with it's context still intact. All mobile operating systems work in the same way. This is because it costs no more power keeping the application cached in memory, and there is no point in freeing memory on the off chance it is needed as it is a waste having empty memory, as it still needs power to refresh it even if it just holds all zeros.

    If you go back to the application that is still in memory it is quicker, and saves power being able to switch it back from memory rather than "load" and run it again from flash memory, which uses more CPU cycles and power to do so.

    I've had Android devices running for 60 days or more before some update or other has meant I've re-started it, and at no point has it slowed down.

    If your device is slowing down it is for some other reason.


  7. Almaz

    Almaz Networkin' Nut Member

    I don't think it's a bug, I had the same issue a long time ago with DD-WRT. It took me 6 month to figure it out but a simple fix just change DTIM Interval from 1 to 10 and that's it. Usually 3 or 5 should be enough.
  8. Toastman

    Toastman Super Moderator Staff Member Member

    Let's agree to disagree on that slowdown point. Reloading an app takes no significant power. Apps that are "cached in memory" and supposedly "frozen" often do. We don't care if an app is badly written, if it was properly terminated then it can't affect the phone. Period.

    As this is way off topic and nothing to do with Tomato, this will be my last word on the subject of Mobile slowdown.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice