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

Status: RESOLVED WORKSFORME

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

Description

[sync-1]

+++ 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

[Andrew Overholt [:overholt]]

Jason, any thoughts on why this is taking so long to pop up?

Comment 2

[Jason Duell]

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.

Comment 3

[Albert [:albert]]

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.

Comment 4

[Salvador de la Puente González [: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.

Comment 5

[Wayne Chang [:wchang]]

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?

Comment 6

[Dietrich Ayala (:dietrich)]

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

[Albert [:albert]]

Have a look to bug 858005

Comment 8

[sync-1]

mozilla have no solution yet 2013-04-15

Comment 9

[Salvador de la Puente González [:salva]]

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.

Comment 10

[jachen]

> 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.

Comment 11

[Jason Duell]

Is this still an issue?  If so I think John Shih might be the person to ask.

Comment 12

[Salvador de la Puente González [:salva]]

It should as proactive alarms are scheduled for 1.3 to landing. See bug 858005.

Comment 13

[Marina Rodríguez [:mai]]

 Resolved by Bug 858017