Closed Bug 962444 Opened 6 years ago Closed 6 years ago

Proposal of moving logic of data usage examination into System app

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:-)

RESOLVED WORKSFORME
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)
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: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.