Closed Bug 850125 Opened 8 years ago Closed 7 years ago

[Buri][Data Usage]Data updating rate is too slow

Categories

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

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:-, b2g18+)

RESOLVED WORKSFORME
1.4 S3 (14mar)
blocking-b2g -
Tracking Status
b2g18 + ---

People

(Reporter: sync-1, Assigned: mai)

References

Details

(Keywords: perf, Whiteboard: [c= p= u= s=2014.03.14])

+++ This bug was initially created as a clone of Bug #416532 +++
 
 DEFECT DESCRIPTION:
 Data updating rate is too slow
 
 REPRODUCING PROCEDURES:
 1.Set "Alert me when used" to "5M";
 2.Then browser some page;
 3.It pop up message when the data has used 8M-->ko
 
 EXPECTED BEHAVIOUR:
 Data updating rate should be more real-time
 
 ASSOCIATE SPECIFICATION:
 
 TEST PLAN REFERENCE:
 
 TOOLS AND PLATFORMS USED:
 
 USER IMPACT:
 
 REPRODUCING RATE:5/5
 
 For FT PR, Please list reference mobile's behavior:
 
 Mozilla Build ID:
 20130304070202
 
 ++++++++++ end of initial bug #416532 description ++++++++++
 
 
 
 CONTACT INFO (Name,Phone number):
 
 DEFECT DESCRIPTION:
 
 REPRODUCING PROCEDURES:
 
 EXPECTED BEHAVIOUR:
 
 ASSOCIATE SPECIFICATION:
 
 TEST PLAN REFERENCE:
 
 TOOLS AND PLATFORMS USED:
 
 USER IMPACT:
 
 REPRODUCING RATE:
 
 For FT PR, Please list reference mobile's behavior:
Jason, any thoughts on why this is taking so long to pop up?
We're measuring data usage right now in an android-specific way (I believe this was in bug 746069). I didn't follow that code--asking acperez, who wrote it.
Flags: needinfo?(acperez)
More than in an android-specific way is in linux-specific way, I don't think the problem is that way of  measuring data. What can be happening here is some bug with cost control app because the current implementation of network stats api does not fit the needs of cost control, thus it is a bit tricky implemented. Anyway I will test the gecko part, but adding Salva to get info from cost control in gaia.
Flags: needinfo?(acperez) → needinfo?(salva)
The problem here is we don't have any back-end mechanism to be aware about how much data has been transmitted: no system message, no alarm-like feature. Just the events of uploading/downloading data. Furthermore, these events are empty, no related info is included with them.

So, from Gaia we are counting number of received events. When they reach a threshold we force a check on the data widget in a very tricky way. We can low the threshold but is very platform coupled and it should be a value high enough to not trigger the checking useless.
Flags: needinfo?(salva)
blocking-b2g: --- → leo?
tracking-b2g18: --- → ?
Depends on: 858005
Triage 4/12 - this is undesirable from user's perspective.

Salvador - according to comment 4, this may not be trivial, is there anything we can work on to improve this?

NI? UX - Jaime, in case this will be difficult to improve technically, can we have some remedy so that the end user expectation is managed?
Flags: needinfo?(salva)
Flags: needinfo?(jachen)
Blocking- because as Salva says, the backend in Gecko is not there yet. Tracking+ so that it stays on the radar for 1.x branch.

Needinfo? for Jason Duell, who might know the right platform bugs for improving the granularity of our ability to track data usage.
blocking-b2g: leo? → -
Flags: needinfo?(jduell.mcbugs)
Have a look to bug 858005
mozilla have no solution yet 2013-04-15
We can make a workaround if transmitted data events include how many bytes have been transmitted. Then we could adjust the granularity in function of how many bytes, not how many events.
Flags: needinfo?(salva)
> NI? UX - Jaime, in case this will be difficult to improve technically, can
> we have some remedy so that the end user expectation is managed?

I would defer to Salvador above because my course of action would be to consult TEF since they were the UX and eng owners on this.
Flags: needinfo?(jachen)
Keywords: perf
Whiteboard: [c= p= u= s=]
Is this still an issue?  If so I think John Shih might be the person to ask.
Flags: needinfo?(jduell.mcbugs)
It should as proactive alarms are scheduled for 1.3 to landing. See bug 858005.
Assignee: nobody → mri
Depends on: 960974
 Resolved by Bug 858017
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
Whiteboard: [c= p= u= s=] → [c= p= u= s=2014.03.14]
Target Milestone: --- → 1.4 S3 (14mar)
You need to log in before you can comment on or make changes to this bug.