Closed Bug 823247 Opened 12 years ago Closed 10 years ago

Wifi should not be disabled in sleep mode

Categories

(Firefox OS Graveyard :: Wifi, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(tracking-b2g:backlog)

RESOLVED FIXED
tracking-b2g backlog

People

(Reporter: whimboo, Unassigned)

References

Details

(Keywords: dogfood, unagi)

Over on bug 802418 I got the information that wifi gets disabled when the device is put into sleep mode. It's to ensure that we save the battery. But I question that this is helpful, especially when the mobile data connection is getting enabled instead. I can't say what the power consumption is for the wifi or the 3G/2G controller but from my experience with other phones and from technical reviews I got that wifi consumes lesser power than a 3G controller. If that's correct, we wouldn't safe the battery but drain it even faster.

Additionally we have to keep in mind that disabling wifi will cause the mobile data connection to be enabled. This will cause extra traffic for the user by data transfers of background applications. As result mobile users with a tiny mobile plan will earlier reach their limit, and will be dropped to 2G or will have to pay extra.

So I think that we should keep the wifi connection enabled in sleep mode as long as it is available. Once you are out of reach we can disable it and make use of the mobile data connection (if enabled by the user). Whenever you come back into the reach, wifi should be automatically reconnected even while the device is in sleep mode. 

Not sure if that can become a blocker but it should at least be discussed.
Additionally I'm not sure about features of possible apps on such a phone, but if we allow background updates for apps while the phone is in sleep mode, e.g. a RSS reader downloading the full article content for offline mode reading, we would use the mobile data connection. Even harder it is if such a download is tied to an active wifi connection. That means whenever you want to update your locally cached articles, you have to turn on your phone to not exceed your mobile traffic over time.
basecamp- as this is intentional behaviour for v1. We can look to change the behaviour in a future version.

Blake - cced you in case you have any comments on this one.
blocking-basecamp: ? → -
When do we actually check for updates? I haven't gotten a notification about an update since 2 days now given that the phone was mostly in sleep mode. Do we only check automatically when wireless is active? That would be another example why it would be important to not disable WIFI in sleep mode.
Flags: needinfo?(dhylands)
My understanding is that it checks once per day.

If it's not online at the time it checks, then it sets up a listener and tries to resume when it comes back online again.
Flags: needinfo?(dhylands)
(In reply to Dave Hylands [:dhylands] from comment #4)
> If it's not online at the time it checks, then it sets up a listener and
> tries to resume when it comes back online again.

Which delay will this listener have? Is it long enough to miss activity which takes about 5 minutes? I really don't get the update notification daily but sporadically whenever I didn't let my phone fall into sleep.
+1 for not disabling wifi when screen goes off, it's really annoying. This should be an opt-in preference under wifi settings.

Even updates are interrupted by this behaviour and a lot of battery is drained switching to 3G and back to wifi+connecting AP...
Bug 859895 - Make wifi timeout build-configurable is landed, we can disable wifi automatically turn off by modifying wifi.screen_off_timeout to 0 in gaia/build/settings.py.
Hi,

I was trying a chat app on a Keon device, and with this behaviour is not possible at all to run an app that should be online all the time.

Shouldn't this be blocker to allow these kind of demanded apps be functional on launch?
blocking-basecamp: - → ?
AFAIK we don't block on basecamp anymore. Moving to leo.
blocking-b2g: --- → leo?
blocking-basecamp: ? → ---
ni? product as current behaviour was previously decided.
Need product to comment if this needs to be reviewed so that Wifi is kept enabled when device enters sleep.
Flags: needinfo?(ffos-product)
For Push notifications, we'd like to keep a connection open for as long as possible. When wifi is disabled on sleep, push has to switch to 3g to receive notifications. This is not a very large data hit when there are no notifications. I've no idea about relative power consumption. On the other hand, if the user is in a place with no 3g/data connectivity, but is connected to wifi, disconnecting the wifi means that push isn't really push anymore. The network stack does not detect when a socket open is attempted. At the least wifi should reconnect if some process tries a network operation.

The other annoying thing when 3g and wifi both are available, with respect to push, is:
1) User connected via WiFi, push socket is over WiFi.
2) Phone goes to sleep, socket switches over to 3G.
3) User gets a notification, switches on display.
4) Sigh... push socket switches over to WiFi again.
This cycle will continue.
Also switching to 3G is a lot more power consuming than Wifi. This means if a leave the phone at night at home, it's going to use my 3G data and more battery.
Product - please renominate if you feel this should be a blocker for a future release.
blocking-b2g: leo? → -
We will consider this for Koi.
blocking-b2g: - → koi?
Flags: needinfo?(ffos-product)
This can be solved by build time configuration in comment 7.

Do we need it to be run time configurable?
Blocks: 891019
UX,

Please comment
Flags: needinfo?(firefoxos-ux-bugzilla)
What is the UX need here? Please clarify and we'll triage. Thanks!
Hi there-
I'm going to assign needs info to Mike in Taipei. He can help to work with Carrie and Juwei to get feedback.

Thanks!
Jaime
Flags: needinfo?(firefoxos-ux-bugzilla) → needinfo?(mtsai)
Hi All, Can anyone prove that ? 
(The WiFi consumes lesser power than a 3G controller)
Flags: needinfo?(kchang)
Excuse me, Are we talking about sleep mode = suspend ? I don't think we have sleep mode or power saving mode in our device. This can cause different solutions and discussions. Thank you.
Flags: needinfo?(mtsai)
Isn't it called sleep mode when you turn off the screen via the power button? That's what I got from various other bugs.
Peter,

What is the expectation here with Wifi. This seems to be going in circles and we need guidance here.
Flags: needinfo?(pdolanjski)
(In reply to Neo Hsieh from comment #20)
> Hi All, Can anyone prove that ? 
> (The WiFi consumes lesser power than a 3G controller)
Theoretically, the wifi component consumes lesser power than a 3G radio component in "connection" mode.
But it is better to directly measure the power consumption of device.
Flags: needinfo?(kchang)
blocking-b2g: koi? → 1.3?
IRC with Pdol this is a feature where requirements are getting spec'ed. So agree with 1.3?
Flags: needinfo?(pdolanjski)
Sandip is checking with the RIL team on the possibility of addressing this in 1.3.
Flags: needinfo?(skamat)
I wonder if we can handle this issue. In current OEM design, wifi can not enter the deep sleep mode. That means the WIFI has more power consumption than 3G data call during the sleep mode.
If we really want to have keep wifi on and have the better power consumption during sleep mode,
we need OEM's support to have a wifi chip/component enabling deep sleep mode.
(In reply to Ken Chang from comment #27)
> I wonder if we can handle this issue. In current OEM design, wifi can not
> enter the deep sleep mode. That means the WIFI has more power consumption
> than 3G data call during the sleep mode.
> If we really want to have keep wifi on and have the better power consumption
> during sleep mode,
> we need OEM's support to have a wifi chip/component enabling deep sleep mode.

Can we just provide the option to enable/disable wifi during sleep mode for v1.3? We can have OEM make the decision of changing the defaults (and further optimizing the power consumption later).
Flags: needinfo?(skamat)
This is being addressed as part of the feature in bug 930972, so I'm duping over there.
Status: NEW → RESOLVED
blocking-b2g: 1.3? → ---
Closed: 11 years ago
Resolution: --- → DUPLICATE
It is not a duplicate of bug 930972, but a blocker for 930972.
Blocks: 930972
Status: RESOLVED → REOPENED
blocking-b2g: --- → 1.4+
Resolution: DUPLICATE → ---
This doesn't fall under the QC blocking feature list & DSDS feature list. Renoming.
blocking-b2g: 1.4+ → 1.4?
blocking-b2g: 1.4? → backlog
Hi Ken, could you help to assign this?
Flags: needinfo?(kchang)
After fixing bug 979130 and 960623, we don't need to fix this. Everyone who want WIFI to keep waking up just can use that wifilock mechanism.
Status: REOPENED → RESOLVED
Closed: 11 years ago10 years ago
Flags: needinfo?(kchang)
Resolution: --- → WONTFIX
(In reply to Ken Chang[:ken] from comment #34)
> After fixing bug 979130 and 960623, we don't need to fix this. Everyone who
> want WIFI to keep waking up just can use that wifilock mechanism.

My original request with that bug was to not get wifi disabled during sleep mode. With the bugs you pointed out here, this got fixed. So not sure why you set this bug as wontfix.
Resolution: WONTFIX → FIXED
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.