Make wifi timeout build-configurable

VERIFIED FIXED in 1.0.1 Madrid (19apr)

Status

P1
normal
VERIFIED FIXED
6 years ago
5 years ago

People

(Reporter: juanpbf, Assigned: timdream)

Tracking

unspecified
1.0.1 Madrid (19apr)
ARM
Gonk (Firefox OS)
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:tef+, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 fixed)

Details

(Whiteboard: IOT, Spain, Ikura, Chile, [status: needs TEF input][madrid])

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
Buildid "20130321070205", ikura.

When screen is off, DuT disconnects from Wi-Fi 

Testing procedure:
1- Connect to Wi-Fi network
2- Turn off the screen.
3- Wait one minute
4- Turn on the screen  

Expected result:
When turning on the screen again, DuT should still be connected to Wifi (and show the icon of Wi-Fi connection).

Current result:
When turning on the screen again, DuT is disconnected from WiFi. If prior to step 1 DuT had mobile data enabled (3G icon is shown), data traffic is consumed
(Cost control was reset and enabled before doing the test, and after the test, it showed that some data was consumed)

This has been reported during Spain certification process. Marked as P1, since it is a blocker for Certification
(Reporter)

Comment 1

6 years ago
Dependency with Telefonica Spain certification process [meta] added. Nominated to tef?
Blocks: 855322
blocking-b2g: --- → tef?

Updated

6 years ago
blocking-b2g: tef? → tef+

Comment 2

6 years ago
Chuck, please look into this problem.
Assignee: nobody → chulee
The "Current result" is what we expect now, to save more power while screen is turned off. While not mentioned in report, but WIFI will reconnect after screen is turned on again.
It's controlled by system app in gaia [1].

Can you provide detail requirement of such certification?

By the way, this seems to be a feature request for a specific partner certification than a system bug to me. Is such patch can be pushed into b2g repo?

[1] http://mxr.mozilla.org/gaia/source/apps/system/js/wifi.js#124
Flags: needinfo?(juan.perezbedmar)

Updated

6 years ago
Whiteboard: IOT, Spain, Ikura
Hi Chuck, 

Thanks for all the details. 

The requirement is to maintain WiFi on in any case, not to switch it off when the screen is off. 

If not configured this way, we have two impacts: 
1. push services will not properly work
2. when turning screen on, sometimes while wifi is doing the SSID scan, 3G mobile data is used instead, which means 3G data consumption

Thanks!
David
(In reply to David Palomino [:dpv] from comment #4)
> 
> The requirement is to maintain WiFi on in any case, not to switch it off
> when the screen is off. 
> 
> If not configured this way, we have two impacts: 
> 1. push services will not properly work
> 2. when turning screen on, sometimes while wifi is doing the SSID scan, 3G
> mobile data is used instead, which means 3G data consumption
> 

Hi David, not sure if this really is cert blocker as I understand that all Windows Phones behave this way (Wifi will be disconnected in screen off mode). 
And at this moment, i do not believe Firefox OS has any major push services and since there is not any major push services, data consumption are mostly user-triggered where the user will know that they are using data when the screen is on. For example if the user decides to launch an app before the wifi reconnects, the user should be aware of it.
and afaik, wifi is turned off in screen off for power saving.
perhaps mvines will have more insights into this with his expertise in platform

Comment 7

6 years ago
We can consider to make it configurable by following options when screen off:
1) Wifi always on
2) Wifi on only if USB connected
3) Wifi always off

Default value can be different depend on requirement.

Updated

6 years ago
OS: Windows 7 → Gonk (Firefox OS)
Hardware: x86_64 → ARM
(In reply to Shian-Yow Wu from comment #7)
> We can consider to make it configurable by following options when screen off:
> 1) Wifi always on
> 2) Wifi on only if USB connected
> 3) Wifi always off
> 
> Default value can be different depend on requirement.

TEF Operators require this to always on (option 1). If you can make this option customisable during build time, it should meet the requirement.

Comment 9

6 years ago
(In reply to Daniel Coloma:dcoloma from comment #8)
> 
> TEF Operators require this to always on (option 1). If you can make this
> option customisable during build time, it should meet the requirement.
If WIFI always on, is there the power consumption criteria for this requirement when screen is
off?

Updated

6 years ago
Flags: needinfo?(dcoloma)
Removing assignee until decision is made.

This is a very late change, and will affect power consumption.
Assignee: chulee → nobody
Whiteboard: IOT, Spain, Ikura → IOT, Spain, Ikura [status: needs TEF input]
Assignee: nobody → janjongboom
Assignee: janjongboom → nobody
(Reporter)

Comment 11

6 years ago
Deleting needinfo tag, as dpv explained it very well in comment 4

Just to give more information, other OS such as Android or Windows Phone gives the user the option to chose what to do when screen is off: either turn-off wifi, or keep it always-on. IMHO, this is the best behaviour and would be accepted by the operator.
Flags: needinfo?(juan.perezbedmar)
If the WiFi chipset on the phone (and access-point) both properly support DTIM > 1, this can go a long way to helping with WiFi idle power consumption.  (But it require the AP to be configured to use DTIM >= 2.)
(In reply to Mike Habicher [:mikeh] from comment #12)
> If the WiFi chipset on the phone (and access-point) both properly support
> DTIM > 1, this can go a long way to helping with WiFi idle power
> consumption.  (But it require the AP to be configured to use DTIM >= 2.)

Do we have such chipset support on our v1.0.1 hardware?

FYI, "Wifi power saving mode" was exposed through API in bug 784733, but Gaia does not use it since where were no feature related to that. Is this the feature?
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #13)
> 
> Do we have such chipset support on our v1.0.1 hardware?

It's part of the standard, so we _should_ support it; but it's a rarely-used feature (most consumer APs ship with DTIM=1) so it's often not well tested; at least one popular chipset driver implements it so badly it's just broken.

Ref. http://en.wikipedia.org/wiki/DTIM

> FYI, "Wifi power saving mode" was exposed through API in bug 784733, but
> Gaia does not use it since where were no feature related to that. Is this
> the feature?

That probably enables APSD: http://en.wikipedia.org/wiki/APSD#APSD

In both cases, the idea is to keep the STA from having to wake up every beacon interval (generally every 100ms) to check for incoming traffic.

Updated

6 years ago
Whiteboard: IOT, Spain, Ikura [status: needs TEF input] → IOT, Spain, Ikura [status: needs TEF input][madrid]

Comment 15

6 years ago
As I known, Wifi chip has power saving ability handled by their micro code already.
OS doesn't need to turn wifi off when in suspend mode.

--
Keven

Comment 16

6 years ago
The other option is: Wifi sleep after screen off for 15 minutes (some Android phones use this way).  This should pass certification process as described in comment 0, also saves power when screen off.

It's best to have a configurable wifi sleep policy, because wifi chip power saving capability is platform dependant, and different operators might have different requirements.  We should create a follow up bug for this.  As I know, it has been discussed before but not included in v1 scope.

Updated

6 years ago
Target Milestone: --- → Madrid (19apr)
I'm clarifying the summary a bit here to reflect what's been requested.

Daniel, please re-clarify if Shian-Yow's 15 minute suggestion in comment 16 is acceptable.
Summary: Wifi connection turned off when screen is off → Create wifi timeout for turning off after screen lock
Keywords: late-l10n
Summary: Create wifi timeout for turning off after screen lock → Make wifi timeout build-configurable
Keywords: late-l10n
A few of us discussed this and have large concerns regarding battery life.  Won't having wifi on all the time severely negatively affect battery life?
Especially for our target markets and users coming from feature phones: we want FFOS devices to be as robust and long-lasting as possible.
Assignee: nobody → timdream

Comment 20

6 years ago
Thank you, Tim!
Created attachment 739572 [details] [review]
Github: https://github.com/mozilla-b2g/gaia/pull/9316

In this patch, the screen off wifi timeout is hooked to mozSetting db "wifi.screen_off_timeout", which can be disabled by set the timeout to 0.
Attachment #739572 - Flags: review?(alive)
Status: UNCONFIRMED → NEW
Ever confirmed: true
master: https://github.com/mozilla-b2g/gaia/commit/8e50cdbfb54f34ccfb58cc9147e5e811471d4a57
Status: NEW → RESOLVED
Last Resolved: 6 years ago
status-b2g18: --- → affected
status-b2g18-v1.0.0: --- → wontfix
status-b2g18-v1.0.1: --- → affected
Resolution: --- → FIXED
Michael, can you comment on this from a power consumption standpoint?  It has come up that versions of Android (all?  prior to current?) did not provide a UI for toggling this (like the current version does).
Flags: needinfo?(mvines)
James, can you assist with the uplift please? :)
Flags: needinfo?(jlal)
v1-train: 3fef920c0e6240919baa2328b966b3e073745de0
v1.0.1: 95d64fcf07db56b329c84a34de38516b1cf55c91

Not sure why this bug is not picked up by jhford's scripts =/ thanks for pointing this out Ryan!
status-b2g18: affected → fixed
status-b2g18-v1.0.1: affected → fixed
Flags: needinfo?(jlal)
(In reply to kkuo from comment #15)
> As I known, Wifi chip has power saving ability handled by their micro code
> already.
> OS doesn't need to turn wifi off when in suspend mode.

Somehow I had missed this when I commented previously about power consumption.  Sorry.
Flags: needinfo?(mvines)
Flags: needinfo?(dcoloma)

Updated

6 years ago
Duplicate of this bug: 864693

Comment 29

6 years ago
Tested on Inari. Commercial RIL: 094. Build ID: 20130506003326
Steps:
1- Connect to Wi-Fi network
2- Turn off the screen.
3- Wait one minute
4- Turn on the screen
Expected result AND Current result:
When turning on the screen again, DuT is still connected to Wifi (and show the icon of Wi-Fi connection).
Status: RESOLVED → VERIFIED
Resolution: FIXED → WORKSFORME

Comment 30

6 years ago
Hi, 

From the log, wifi closed is due to the application action. The command of Terminate is sent to libhardware_legacy.so, and then also used wifi_stop_supplicant(). Please help to check whether it is like this.

01-06 00:15:00.370   110   274 E WifiHW  : 'TERMINATE'
01-06 00:15:00.430   484   484 I wpa_supplicant: wlan0: CTRL-EVENT-TERMINATING 
01-06 00:15:00.860   110   274 E WifiHW  : wifi_stop_supplicant() enter stop wpa_supplicant

Thanks.
(In reply to bov from comment #29)
> Tested on Inari. Commercial RIL: 094. Build ID: 20130506003326
> Steps:
> 1- Connect to Wi-Fi network
> 2- Turn off the screen.
> 3- Wait one minute
> 4- Turn on the screen
> Expected result AND Current result:
> When turning on the screen again, DuT is still connected to Wifi (and show
> the icon of Wi-Fi connection).

bov, please stop switching FIXED bug to WORKSFORME. Thanks!

https://bugzilla.mozilla.org/page.cgi?id=fields.html#status
Resolution: WORKSFORME → FIXED

Comment 32

6 years ago
(In reply to TangJuan from comment #30)
> Hi, 
> 
> From the log, wifi closed is due to the application action. The command of
> Terminate is sent to libhardware_legacy.so, and then also used
> wifi_stop_supplicant(). Please help to check whether it is like this.
> 
> 01-06 00:15:00.370   110   274 E WifiHW  : 'TERMINATE'
> 01-06 00:15:00.430   484   484 I wpa_supplicant: wlan0:
> CTRL-EVENT-TERMINATING 
> 01-06 00:15:00.860   110   274 E WifiHW  : wifi_stop_supplicant() enter stop
> wpa_supplicant
> 
> Thanks.

With today's sync from git, I still can't reproduce this issue. Can you offer me more about the environment you used? The fail rate you found? Thanks.

Comment 33

6 years ago
(In reply to TangJuan from comment #30)
> Hi, 
> 
> From the log, wifi closed is due to the application action. The command of
> Terminate is sent to libhardware_legacy.so, and then also used
> wifi_stop_supplicant(). Please help to check whether it is like this.
> 
> 01-06 00:15:00.370   110   274 E WifiHW  : 'TERMINATE'
> 01-06 00:15:00.430   484   484 I wpa_supplicant: wlan0:
> CTRL-EVENT-TERMINATING 
> 01-06 00:15:00.860   110   274 E WifiHW  : wifi_stop_supplicant() enter stop
> wpa_supplicant
> 
> Thanks.

Can you please also provide the latest git commit id you saw in gecko and gaia folder and I can sync with your environment.

Comment 34

6 years ago
No longer blocking khepera_43487.  Adding dependency to Chile IOT metabug.
Blocks: 855378
Whiteboard: IOT, Spain, Ikura [status: needs TEF input][madrid] → IOT, Spain, Ikura, Chile, [status: needs TEF input][madrid]

Comment 35

6 years ago
Sometimes the wifi can not re-connect itself when screen is on, any one else encounter this problem ?
Attachment mime type: text/plain → text/x-github-pull-request
You need to log in before you can comment on or make changes to this bug.