859895 - Make wifi timeout build-configurable

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Wifi, defect, P1)

Description

[Juan Perez-Bedmar [:juanpbf]]

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

Comment 1

[Juan Perez-Bedmar [:juanpbf]]

Dependency with Telefonica Spain certification process [meta] added. Nominated to tef?

Comment 2

[Ken Chang[:kenkai]]

Chuck, please look into this problem.

Comment 3

[Chuck Lee [:chucklee, Triggered by NI, Review, and Feedback requests]]

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

Comment 4

[David Palomino [:dpalomino]]

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

Comment 5

[Joe Cheng [:jcheng] (please needinfo)]

(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.

Comment 6

[Joe Cheng [:jcheng] (please needinfo)]

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

[Shian-Yow Wu [:swu]]

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.

Comment 8

[Daniel Coloma:dcoloma]

(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

[Ken Chang[:kenkai]]

(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?

Comment 10

[Dietrich Ayala (:dietrich)]

Removing assignee until decision is made.

This is a very late change, and will affect power consumption.

Comment 11

[Juan Perez-Bedmar [:juanpbf]]

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.

Comment 12

[Mike Habicher [:mikeh] (high bugzilla latency)]

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.)

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(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?

Comment 14

[Mike Habicher [:mikeh] (high bugzilla latency)]

(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.

Comment 15

[Keven Kuo [:kkuo]]

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

[Shian-Yow Wu [:swu]]

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.

Comment 17

[Andrew Overholt [:overholt]]

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.

Comment 18

[Andrew Overholt [:overholt]]

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?

Comment 19

[Josh Carpenter [:jcarpenter]]

Especially for our target markets and users coming from feature phones: we want FFOS devices to be as robust and long-lasting as possible.

Comment 20

[Kai-Chih Hu [:khu]]

Thank you, Tim!

Comment 21

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: 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.

Comment 22

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 739572 [details] [review]
Github: https://github.com/mozilla-b2g/gaia/pull/9316

r=me, thanks.

Comment 23

[Tim Guan-tin Chien [:timdream] (please needinfo)]

master: https://github.com/mozilla-b2g/gaia/commit/8e50cdbfb54f34ccfb58cc9147e5e811471d4a57

Comment 24

[Andrew Overholt [:overholt]]

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).

Comment 25

[Ryan VanderMeulen [:RyanVM]]

James, can you assist with the uplift please? :)

Comment 26

[James Lal [:lightsofapollo]]

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!

Comment 27

[Andrew Overholt [:overholt]]

(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.

Comment 29

[bov]

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).

Comment 30

[TangJuan]

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.

Comment 31

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(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

Comment 32

[Vincent Liu[:vliu]]

(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

[Vincent Liu[:vliu]]

(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

[John Hammink]

No longer blocking khepera_43487.  Adding dependency to Chile IOT metabug.

Comment 35

[buri.blff]

Sometimes the wifi can not re-connect itself when screen is on, any one else encounter this problem ？