Closed
Bug 850125
Opened 12 years ago
Closed 11 years ago
[Buri][Data Usage]Data updating rate is too slow
Categories
(Firefox OS Graveyard :: Gaia::Cost Control, defect, P2)
Tracking
(blocking-b2g:-, b2g18+)
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:
Comment 1•12 years ago
|
||
Jason, any thoughts on why this is taking so long to pop up?
Comment 2•12 years ago
|
||
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)
Comment 3•12 years ago
|
||
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)
Comment 4•12 years ago
|
||
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)
Updated•12 years ago
|
Comment 5•12 years ago
|
||
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)
Comment 6•12 years ago
|
||
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.
Comment 7•12 years ago
|
||
Have a look to bug 858005
Comment 9•12 years ago
|
||
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)
Comment 10•12 years ago
|
||
> 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)
Comment 11•11 years ago
|
||
Is this still an issue? If so I think John Shih might be the person to ask.
Flags: needinfo?(jduell.mcbugs)
Comment 12•11 years ago
|
||
It should as proactive alarms are scheduled for 1.3 to landing. See bug 858005.
Assignee | ||
Updated•11 years ago
|
Assignee: nobody → mri
Assignee | ||
Comment 13•11 years ago
|
||
Resolved by Bug 858017
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
Updated•11 years ago
|
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.
Description
•