1050179 - Ingestion reports show inaccurate elapsed time since data received

Status: RESOLVED WONTFIX

(Datazilla Graveyard :: General, defect)

Description

[Dave Hunt [:davehunt] [he/him] ⌚BST]

About a week ago we stopped sending data to the 'flame' device type (it is now split between 'flame-319MB' and 'flame-512MB'). As expected, we now get ingestion alerts for the 'flame' device, however the days since data seem to be inaccurate.

Here's the latest report:

Device Type: flame, Product: B2G, master, prerelease
------------------------------------------------------------
Test: cold_load_time
   App: messages, no data in 57 days, 7 hours, 59 minutes
   App: settings, no data in 57 days, 7 hours, 52 minutes
   App: gallery, no data in 57 days, 7 hours, 44 minutes
   App: video, no data in 57 days, 7 hours, 37 minutes
   App: music, no data in 57 days, 7 hours, 26 minutes
   App: email, no data in 57 days, 7 hours, 12 minutes
   App: calendar, no data in 57 days, 7 hours, 5 minutes
   App: clock, no data in 57 days, 6 hours, 58 minutes
   App: usage, no data in 57 days, 6 hours, 44 minutes
   App: template, no data in 57 days, 6 hours, 37 minutes
   App: browser, no data in 7 days, 21 hours, 53 minutes
   App: fm_radio, no data in 7 days, 21 hours, 52 minutes
   App: camera, no data in 7 days, 21 hours, 51 minutes
   App: phone, no data in 7 days, 21 hours, 50 minutes
   App: contacts, no data in 7 days, 21 hours, 49 minutes

While the last five rows seem to be accurate, the line that proceed them imply that there has been no data for 57+ days. I don't have any data to back this up, but I do not feel that this is correct.

Comment 1

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Byron: Jonathan thought you might be able to help out here?

Comment 2

[:glob ✱]

unfortunately i don't have any access to the database, making any datazilla diagnostic work near impossible for me i'm sorry.

Comment 3

[Dave Hunt [:davehunt] [he/him] ⌚BST]

(In reply to Byron Jones ‹:glob› from comment #2)
> unfortunately i don't have any access to the database, making any datazilla
> diagnostic work near impossible for me i'm sorry.

Okay, thanks. Perhaps Jeads can help?

Comment 4

[Jonathan Eads ( :jeads )]

Looking at all of the occurrences of 'flame' in the machine table we see this:

mysql> select m.name, m.type, o.name, o.version from machine as m join operating_system as o on m.operating_system_id = o.id where m.type = 'flame';
+-------------------+-------+------------+--------------------+
| name              | type  | name       | version            |
+-------------------+-------+------------+--------------------+
| 24:0a:11:e2:20:ea | flame | Firefox OS | 2.1.0.0-prerelease |
| 24:0a:11:7e:5a:a1 | flame | Firefox OS | 2.1.0.0-prerelease |
+-------------------+-------+------------+--------------------+
2 rows in set (0.04 sec)

It's possible that the flame device associations were corrupted due to the re-used machine name issue described here https://bugzilla.mozilla.org/show_bug.cgi?id=1046056#c4. This could end in incorrect date associations depending on when a machine name was first received. 

When the corrupted data in Bug 1046056 is fixed this might go away, if not I will look into it again.

Comment 5

[Jonathan Griffin (:jgriffin)]

B2G perf data is now being visualized at http://raptor.mozilla.org