Closed Bug 962444 Opened 11 years ago Closed 11 years ago

Proposal of moving logic of data usage examination into System app

Categories

(Firefox OS Graveyard :: Gaia::Cost Control, defect)

Product:
Firefox OS Graveyard
Component:
Gaia::Cost Control
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(blocking-b2g:-)

Status:
RESOLVED WORKSFORME
Project Flags:
blocking-b2g -

People

(Reporter: dwi2, Unassigned)

Details

According to https://bugzilla.mozilla.org/show_bug.cgi?id=959054#c7 We are unable to monitor data usage and sent data usage exceeding notification in time if we do not launch cost control widget when phone boot up We are considering to moving the logic of checking data usage and notification into system app, so that we don't have to launch cost control widget at booting up time but keep the same functionality as before.
The flow will possibly be: When phone boot up, there will be no iframe of cost control widget but a data usage tracking module to be brought up in System app. When data usage exceed data limit, the data usage tracking module (in System app) will launch Cost Control widget in an iframe of utility tray. Then widget will redo the calculation and send out a notification of exceeding data limit. The problem is: we need to sync data between indexDB in Cost Control app and indexDB in System app. Since cost control keep data usage limit of current tracking period in indexDB, we will need to keep exact the same data in indexDB in System app too (which is quite redundant.)
Summary: Proposal of moving functionality of data usage examination and notification into System app → Proposal of moving logic of data usage examination into System app
If we decided to do this, I'll need 2 to 3 weeks to finish it.
Whiteboard: [tarako]
Also I noticed that there is a NetworkStatsAlarm in Gecko http://mxr.mozilla.org/mozilla-central/source/dom/network/interfaces/nsIDOMNetworkStatsManager.idl#46 I guess it is 'the data usage alarm' mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=858017#2 If we could ever utilize this API, then it won't be necessary to do things in comment 1.
according to https://bugzilla.mozilla.org/show_bug.cgi?id=858017#2 NetworkStatsAlarm should be already existed in v1.3
Tzu-lin, Please be aware of bug 959054 comment 10. Thanks.
Flags: needinfo?(tzhuang)
Thanks for reminding, Tim. If bug 960974 could be fixed as scheduled (since it is marked as 1.3+), I think we could still utilize NetworkStatsAlarm API to do keep track of data usage in System app.
Flags: needinfo?(tzhuang)
We need bug 858017 as the proper fix, not bug 960974.
Hi, I have a concern about what do you need exactly? Do you need proactive alarms or get rid of the Usage process at the start of the device?
Flags: needinfo?(timdream)
(In reply to Salvador de la Puente González [:salva] from comment #8) > Hi, I have a concern about what do you need exactly? Do you need proactive > alarms or get rid of the Usage process at the start of the device? Yes. And we also need the process being push back to it's original background OOM priority when the widget and app frame are not visible.
Flags: needinfo?(timdream)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #9) > (In reply to Salvador de la Puente González [:salva] from comment #8) > > Hi, I have a concern about what do you need exactly? Do you need proactive > > alarms or get rid of the Usage process at the start of the device? > > Yes. And we also need the process being push back to it's original > background OOM priority when the widget and app frame are not visible. Excuse me Tim, should I understand you need both? And about the background OOM priority, I don't understand the problem, the widget visibility is set to false when it is not visible so what is the current problem?
Flags: needinfo?(timdream)
(In reply to Salvador de la Puente González [:salva] from comment #10) > (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from > comment #9) > > (In reply to Salvador de la Puente González [:salva] from comment #8) > > > Hi, I have a concern about what do you need exactly? Do you need proactive > > > alarms or get rid of the Usage process at the start of the device? > > > > Yes. And we also need the process being push back to it's original > > background OOM priority when the widget and app frame are not visible. > > Excuse me Tim, should I understand you need both? I don't understand the question. We need to get rid of the Usage process at the start of the device, and the necessary of having the Usage process persistent for monitoring network/sms/calls etc. According to bug 959054 comment 10 that's exactly what bug 858017 is about, if I am reading the comment and the bug correctly. (I am probably wrong here, please correct me) > And about the background OOM priority, I don't understand the problem, the > widget visibility is set to false when it is not visible so what is the > current problem? I am told the Usage process is launched with higher-than-background OOM priority, but I am not sure why is that. Maybe people had looking at the wrong thing all along or maybe that is caused by system message handling, or something else. It would be preferable to not to do that too.
Flags: needinfo?(timdream)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #11) > We need to get rid of the Usage process at the start of the device, and the > necessary of having the Usage process persistent for monitoring > network/sms/calls etc. According to bug 959054 comment 10 that's exactly > what bug 858017 is about, if I am reading the comment and the bug correctly. > > (I am probably wrong here, please correct me) After some research, to avoid starting the usage process, we must solve the alarm bug 858017 and this other: bug 943343. > > > And about the background OOM priority, I don't understand the problem, the > > widget visibility is set to false when it is not visible so what is the > > current problem? > > I am told the Usage process is launched with higher-than-background OOM > priority, but I am not sure why is that. Maybe people had looking at the > wrong thing all along or maybe that is caused by system message handling, or > something else. It would be preferable to not to do that too. Here are some numbers I collected in some situations and given OOM priority 2 is foreground and 10 is background, I did not see any unusual: Just started: ------------- | megabytes | NAME PID NICE USS PSS RSS VSIZE OOM_ADJ USER b2g 133 0 55.2 59.8 71.4 167.1 0 root Usage 359 18 9.1 12.4 22.6 66.1 11 app_359 Homescreen 418 1 19.2 23.5 34.8 90.0 2 app_418 (Preallocated a 422 18 9.8 12.6 21.8 61.1 10 app_422 Utility tray down: ------------------ | megabytes | NAME PID NICE USS PSS RSS VSIZE OOM_ADJ USER b2g 133 0 48.4 52.0 64.8 160.6 0 root Usage 359 1 13.2 16.3 28.5 74.1 2 app_359 Homescreen 418 1 16.8 20.1 32.6 88.9 2 app_418 Built-in Keyboa 422 18 11.6 14.4 26.1 76.1 10 app_422 (Preallocated a 532 18 8.9 11.4 22.0 64.1 10 root Utility tray up: ---------------- | megabytes | NAME PID NICE USS PSS RSS VSIZE OOM_ADJ USER b2g 133 0 48.1 51.8 64.6 159.6 0 root Usage 359 18 12.6 15.7 27.9 68.2 10 app_359 Homescreen 418 1 16.8 20.1 32.6 87.9 2 app_418 Built-in Keyboa 422 18 11.6 14.4 26.1 75.1 11 app_422 (Preallocated a 532 18 8.9 11.4 22.0 63.1 10 root Cost Control app open and in foreground: ---------------------------------------- | megabytes | NAME PID NICE USS PSS RSS VSIZE OOM_ADJ USER b2g 133 0 46.7 51.5 65.8 167.5 0 root Usage 359 1 25.2 30.0 44.3 135.7 2 app_359 Homescreen 418 18 15.3 18.6 31.2 73.2 8 app_418 Built-in Keyboa 422 18 11.6 14.4 26.1 75.1 11 app_422 (Preallocated a 532 18 8.9 11.4 22.0 63.1 10 root Cost Control app open and in backgrouond: ----------------------------------------- | megabytes | NAME PID NICE USS PSS RSS VSIZE OOM_ADJ USER b2g 133 0 47.3 53.2 68.7 171.2 0 root Homescreen 418 1 16.4 20.6 34.0 117.1 2 app_418 Built-in Keyboa 422 18 11.5 14.4 26.1 75.1 11 app_422 Usage 613 18 21.2 26.3 40.9 107.7 10 app_613 (Preallocated a 619 18 8.9 11.4 22.0 65.1 10 root Cost Control app open, in foreground and utlity tray down: ---------------------------------------------------------- | megabytes | NAME PID NICE USS PSS RSS VSIZE OOM_ADJ USER b2g 133 0 47.6 52.8 67.4 168.0 0 root Homescreen 418 18 15.4 18.8 31.4 74.2 8 app_418 Built-in Keyboa 422 18 11.5 14.4 26.1 75.1 11 app_422 Usage 613 1 24.4 29.6 44.3 133.6 2 app_613 (Preallocated a 619 18 8.9 11.4 22.0 64.1 10 root Can you double-check the OOM issue, please?
Flags: needinfo?(timdream)
Thanks for your detail reply! (In reply to Salvador de la Puente González [:salva] from comment #12) > (In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from > comment #11) > > We need to get rid of the Usage process at the start of the device, and the > > necessary of having the Usage process persistent for monitoring > > network/sms/calls etc. According to bug 959054 comment 10 that's exactly > > what bug 858017 is about, if I am reading the comment and the bug correctly. > > > > (I am probably wrong here, please correct me) > > After some research, to avoid starting the usage process, we must solve the > alarm bug 858017 and this other: bug 943343. > Good. Per e-mail sent by Joe, do we have an ETA of bug 858017 and dependencies? We would like to know if it's possible for it to reach v1.3t. For bug 943343 there is already a patch, so I am not too worry. > > > > > And about the background OOM priority, I don't understand the problem, the > > > widget visibility is set to false when it is not visible so what is the > > > current problem? > > > > I am told the Usage process is launched with higher-than-background OOM > > priority, but I am not sure why is that. Maybe people had looking at the > > wrong thing all along or maybe that is caused by system message handling, or > > something else. It would be preferable to not to do that too. > > Here are some numbers I collected in some situations and given OOM priority > 2 is foreground and 10 is background, I did not see any unusual: > > Just started: > ------------- > > | megabytes | > NAME PID NICE USS PSS RSS VSIZE OOM_ADJ USER > b2g 133 0 55.2 59.8 71.4 167.1 0 root > Usage 359 18 9.1 12.4 22.6 66.1 11 app_359 > Homescreen 418 1 19.2 23.5 34.8 90.0 2 app_418 > (Preallocated a 422 18 9.8 12.6 21.8 61.1 10 app_422 > > Utility tray down: > ------------------ > > | megabytes | > NAME PID NICE USS PSS RSS VSIZE OOM_ADJ USER > b2g 133 0 48.4 52.0 64.8 160.6 0 root > Usage 359 1 13.2 16.3 28.5 74.1 2 app_359 > Homescreen 418 1 16.8 20.1 32.6 88.9 2 app_418 > Built-in Keyboa 422 18 11.6 14.4 26.1 76.1 10 app_422 > (Preallocated a 532 18 8.9 11.4 22.0 64.1 10 root > > Utility tray up: > ---------------- > > | megabytes | > NAME PID NICE USS PSS RSS VSIZE OOM_ADJ USER > b2g 133 0 48.1 51.8 64.6 159.6 0 root > Usage 359 18 12.6 15.7 27.9 68.2 10 app_359 > Homescreen 418 1 16.8 20.1 32.6 87.9 2 app_418 > Built-in Keyboa 422 18 11.6 14.4 26.1 75.1 11 app_422 > (Preallocated a 532 18 8.9 11.4 22.0 63.1 10 root > > Cost Control app open and in foreground: > ---------------------------------------- > > | megabytes | > NAME PID NICE USS PSS RSS VSIZE OOM_ADJ USER > b2g 133 0 46.7 51.5 65.8 167.5 0 root > Usage 359 1 25.2 30.0 44.3 135.7 2 app_359 > Homescreen 418 18 15.3 18.6 31.2 73.2 8 app_418 > Built-in Keyboa 422 18 11.6 14.4 26.1 75.1 11 app_422 > (Preallocated a 532 18 8.9 11.4 22.0 63.1 10 root > > Cost Control app open and in backgrouond: > ----------------------------------------- > > | megabytes | > NAME PID NICE USS PSS RSS VSIZE OOM_ADJ USER > b2g 133 0 47.3 53.2 68.7 171.2 0 root > Homescreen 418 1 16.4 20.6 34.0 117.1 2 app_418 > Built-in Keyboa 422 18 11.5 14.4 26.1 75.1 11 app_422 > Usage 613 18 21.2 26.3 40.9 107.7 10 app_613 > (Preallocated a 619 18 8.9 11.4 22.0 65.1 10 root > > Cost Control app open, in foreground and utlity tray down: > ---------------------------------------------------------- > > | megabytes | > NAME PID NICE USS PSS RSS VSIZE OOM_ADJ USER > b2g 133 0 47.6 52.8 67.4 168.0 0 root > Homescreen 418 18 15.4 18.8 31.4 74.2 8 app_418 > Built-in Keyboa 422 18 11.5 14.4 26.1 75.1 11 app_422 > Usage 613 1 24.4 29.6 44.3 133.6 2 app_613 > (Preallocated a 619 18 8.9 11.4 22.0 64.1 10 root > > Can you double-check the OOM issue, please? Thinker, could you reassign someone to verify this?
Flags: needinfo?(timdream) → needinfo?(tlee)
mark 1.3T?
blocking-b2g: --- → 1.3T?
Whiteboard: [tarako]
hi Tim, if bug 858017 will land, do we still need this for tarako? thanks
Flags: needinfo?(timdream)
(In reply to Joe Cheng [:jcheng] from comment #15) > hi Tim, if bug 858017 will land, do we still need this for tarako? thanks We will need _either_ bug 858017 _or_ this bug on v1.3t branch. So the answer is no.
Flags: needinfo?(timdream)
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #16) > (In reply to Joe Cheng [:jcheng] from comment #15) > > hi Tim, if bug 858017 will land, do we still need this for tarako? thanks > > We will need _either_ bug 858017 _or_ this bug on v1.3t branch. > > So the answer is no. Given 858017 is blocking 1.3T, removing the nom here.
blocking-b2g: 1.3T? → -
Flags: needinfo?(tlee)
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.