Modify

Opened 7 years ago

Last modified 3 years ago

#9482 reopened defect

ath9k - Excessive battery drainage of connected smartphones

Reported by: anonymous Owned by: developers
Priority: normal Milestone: Backfire 10.03.1
Component: packages Version: Backfire 10.03.1 RC4
Keywords: Cc:

Description

After compiling the Backfire build r27002, I can observe a drastic increase of battery consumption of all the smartphones connected to an ar9160 card, at least the double of my previous build r26317. This is particularly noticeable when the phones are on stand-by performing only the apps synchronizations like e-mails and instant messaging.

Attachments (0)

Change History (20)

comment:1 follow-up: Changed 7 years ago by nbd

Did you verify this by switching between the new build and the old build a few times and measuring the difference?

comment:2 in reply to: ↑ 1 Changed 7 years ago by anonymous

Replying to nbd:

Did you verify this by switching between the new build and the old build a few times and measuring the difference?

Yes I did before posting. It's very obvious on all the phones.

comment:3 follow-up: Changed 7 years ago by nbd

Is the difference also visible if you disable 802.11n?

comment:4 in reply to: ↑ 3 Changed 7 years ago by anonymous

Replying to nbd:

Is the difference also visible if you disable 802.11n?

I've switched now to g only for an assessment. Give me a day or two for a feedback.

comment:5 Changed 7 years ago by anonymous

I'm getting similar problem on N900. Initially after router boot-up, all things are fine. But after some hours or days of uptime, AP does something weird what prevents phone's wi-fi from entering into powersave mode. This kills battery in a matter of hours.

When this happens, phone's dmesg (it's N900, running Linux as well, it's .g only) flooded by messages about beacons loss and that this causes phone to re-send probe to AP. It is impossible that so many beacons are lost when phone is 1 meter away from router's antenna, furthermore, rebooting router corrects this problem. Looks like ath9k can go mad and does something wrong with beacons or something like this.

comment:6 Changed 7 years ago by nbd

Please try if this issue is also present in trunk, and also mention what kind of hardware you're using on the AP side.

comment:7 Changed 7 years ago by anonymous

After 24 hours in g mode only, I couldn't see any excessive battery consumption. It's as good as with build r26317 in n mode. I've got an ar9160 card plugged into an Alix 2d3 board.

comment:8 Changed 7 years ago by anonymous

nbd, I tried with trunk r27142 : same thing, it's a battery killer in "n" mode.

comment:9 Changed 7 years ago by nbd

please try a more recent version, lots of fixes went in, some of which might be related.

comment:10 Changed 7 years ago by nbd

  • Resolution set to no_response
  • Status changed from new to closed

comment:11 Changed 3 years ago by atomaniac

  • Resolution no_response deleted
  • Status changed from closed to reopened

I have the same issue with HT mode (802.11n) set to Disabled.
The smartphones connected via WiFi suffer excessive battery drainage (Symbian and Android smartphones). There was no such issue with Attitude Adjustment 12.09.

Here is my current config:
TP-Link TL-WR740N/ND v4
Barrier Breaker 14.07-rc3 / LuCI Trunk (svn-r10467)
Kernel Version 3.10.49

comment:12 Changed 3 years ago by anonymous

at least try 14.07 final before reopening this ticket. there were several ath9k fixes between rc3 and final.

comment:13 Changed 3 years ago by atomaniac

Updating to Barrier Breaker 14.07 Final (02-Oct-2014) did not bring any improvements for the situation.
Rolling back to Attitude Adjustment 12.09 (03-Apr-2013) without any changes in the (symbian) smartphone config as well as in the router settings fixed the issue. Would be glad to provide any required information for tracing the issue.
In the symbian WLAN stats I can see that with 12.09 firmware it is exchanging packets with the router approx once in 10 secs or less often when idle. While with 14.07 it never stops exchanging, It does it each second which drains the battery.

comment:14 Changed 3 years ago by nbd

do you have another router that you could use in monitor mode to capture the exchange between your phone and your AP? it would be useful if you could make a capture for me from the moment the phone connects to the point where the problems are visible.

comment:15 Changed 3 years ago by nbd

  • Resolution set to no_response
  • Status changed from reopened to closed

comment:16 Changed 3 years ago by Jan-openwrt-trac@…

  • Resolution no_response deleted
  • Status changed from closed to reopened

Hi i also experience the very same problem with an S3 Mini and at least three different ar71xx openwrt devices. Any further ideas how to debug this? I can easily reproduce the issue with all devices.

comment:17 Changed 3 years ago by nbd

with what openwrt version?

comment:18 Changed 3 years ago by Jan-openwrt-trac@…

It also worked for me in Attitude Adjustment 12.09. Problems started when updating to Barrier Breaker 14.07 final. Same problem still exists in trunk/Chaos Calmer. Happens in both 2.4 and 5Ghz. Roaming still works when problem occurs.

When the problems occur I can see periodic ARP requests from to phone asking for the MAC of the gateway (which is also DNS server). The gateway responds but the phone seems to miss the response. Phone recovers after a few minutes or when i restart the wireless at the phone. When the phone recovers I noticed the rate at the AP to drop to 1MBit/s. May be the phone goes to powersave mode but the AP still uses a high rate to send packets?

comment:19 Changed 3 years ago by nbd

What devices are you using, and what was the last revision of Chaos Calmer that you tested?

comment:20 Changed 3 years ago by Jan-openwrt-trac@…

Last version is CHAOS CALMER (Bleeding Edge, r45306). Devices are:

  • TP-Link TL-WR740N
  • TP-Link TL-WR841ND (two units)
  • TP-Link TL-WDR3600

Add Comment

Modify Ticket

Action
as reopened .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.