1201671 - Telemetry Environment: add CPU Vendor, Family and Stepping per environment spec on Fennec

Status: RESOLVED INVALID

(Toolkit :: Telemetry, defect, P4)

Description

[Milan Sreckovic [:milan] (needinfo for best results)]

+++ This bug was initially created as a clone of Bug #1128472 +++

We should add CPU Vendor, Family, Model and Stepping to the Telemetry Environment as per the Environment Spec (bug 1069880).

This, but for Fennec.  Separating the bug to simplify things.

Comment 1

[Milan Sreckovic [:milan] (needinfo for best results)]

Bug 1128472 covers the desktop platforms.

Comment 2

[Georg Fritzsche [:gfritzsche]]

Is there a specific request/need to add this on Fennec?
Otherwise we might want to wait with further Fennec features until the mobile team made decisions on what measurements system they want to build on in the future.

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

Good question - the request was made by the games team in bug 1184784, to cover desktop and mobile, and I'm not clear on the measurement system topic.

Comment 4

[Andre Vrignaud [:andre] [Seattle - PST]]

There is a need to add this in Fennec, as well as iOS. Goal is to be able to collect hardware specification data on all devices Firefox is available on, so we can aggregate and share in anonymized way to developers so they can target the appropriate sweet spot (perf/volume) appropriate to their game. We plan to share on a public-facing website similarly to what Valve does with their PC Hardware Survey.

Do we have an ETA on when any future mobile team measurements system will be available? If not, probably should implement this sooner so we can use to tell the market opportunity story.

Comment 5

[Georg Fritzsche [:gfritzsche]]

Note that Telemetry on Fennec will - per the current status - only collect data from people who opted into Telemetry collection.
FHR currently is active by default for all release users on Fennec.
So, we could either do it in FHR right now or wait on the future direction of mobile measurement.

Mark, is that something worth waiting on and is my understanding regarding the re-evluation correct?

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

Georg - I'd rather add this to Telemetry, if it's not already there. I don't think we should add any new data to FHR. In fact, I'd like to see what parts of Unified Telemetry are already functional in Fennec and create a plan to move away from FHR (bug 1183320)

If we need to get Unified Telemetry reporting by default on Release, we could file a bug to get that started. In the meantime, the number of Release users with Telemetry enabled will have to be good enough.

Comment 7

[Andre Vrignaud [:andre] [Seattle - PST]]

Couple of comments:

- Having this hardware survey data from the widest possible audience is key, and has been approved conceptually by JST. So, believe we should be aiming for opt-out here (no matter what the data source).

- That said, if Telemetry is the future direction of data collection, would seem to make sense to "simply" add the hardware collection items to an opt-out whitelist or other way to make sure we gather from the larger audience.

- Key question: if collecting this hardware data in an opt-out manner using Telemetry is tied to "future direction of mobile measurement", how far off is this? Right now the games program "big bang" (new brand/website/data being published) is coalescing around March of 2016. Would hope to have initial data flowing several months before so we could tune/tweak before publishing.

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to avrignaud from comment #7)
> Couple of comments:
> 
> - Having this hardware survey data from the widest possible audience is key,
> and has been approved conceptually by JST. So, believe we should be aiming
> for opt-out here (no matter what the data source).

If the current audience is ZERO on Fennec, getting even some portion of our Release population would be of benefit. If normal Telemetry is all we can do for Fennec, then you get opt-in groups on Release and opt-out groups on Beta. If Unified Telemetry is enabled in Fennec, then you get opt-out groups on Release too.

I don't know the status of Unified Telemetry on Fennec. We could query the current environment and see what data is being sent.

> - That said, if Telemetry is the future direction of data collection, would
> seem to make sense to "simply" add the hardware collection items to an
> opt-out whitelist or other way to make sure we gather from the larger
> audience.

That sounds like Unified Telemetry anyway.

> - Key question: if collecting this hardware data in an opt-out manner using
> Telemetry is tied to "future direction of mobile measurement", how far off
> is this? Right now the games program "big bang" (new brand/website/data
> being published) is coalescing around March of 2016. Would hope to have
> initial data flowing several months before so we could tune/tweak before
> publishing.

The Mobile team needs some support from the Telemetry team to make it happen. Mobile alone does not have the bandwidth or domain knowledge to handle it completely.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

Based on the way bug 1128472 was implemented, you just need to add an Android #ifdef block and put the values into the SystemInfo property bag.

Comment 10

[Vladan Djeric (:vladan)]

For the record, we don't have enough info in these fields to identify specific CPU models. When I Google my CPU's Family Number/Model Number/Stepping/Frequency (6/42/7/2292) -- I see many matching CPUS: http://www.speedtraq.com/

Is there any way to get the CPU model string? (maybe a different bug)

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

(In reply to Vladan Djeric (:vladan) -- please needinfo! from comment #10)
> For the record, we don't have enough info in these fields to identify
> specific CPU models. When I Google my CPU's Family Number/Model
> Number/Stepping/Frequency (6/42/7/2292) -- I see many matching CPUS:
> http://www.speedtraq.com/
> 
> Is there any way to get the CPU model string? (maybe a different bug)

I'm sure we could - are you sure the combination of family/model/stepping/frequency and # cores doesn't do it?

Comment 12

[Georg Fritzsche [:gfritzsche]]

(In reply to Mark Finkle (:mfinkle) from comment #8)
> (In reply to avrignaud from comment #7)
> > Couple of comments:
> > 
> > - Having this hardware survey data from the widest possible audience is key,
> > and has been approved conceptually by JST. So, believe we should be aiming
> > for opt-out here (no matter what the data source).
> 
> If the current audience is ZERO on Fennec, getting even some portion of our
> Release population would be of benefit. If normal Telemetry is all we can do
> for Fennec, then you get opt-in groups on Release and opt-out groups on
> Beta. If Unified Telemetry is enabled in Fennec, then you get opt-out groups
> on Release too.
> 
> I don't know the status of Unified Telemetry on Fennec. We could query the
> current environment and see what data is being sent.

The data being submitted is mostly the same (except where documented in [0] etc.).

Some things are disabled on Fennec for now that would need decisions/investigations first.
We could add this data to Telemetry on Fennec now and use it from the current submissions right away (and then just get more data later if Telemetry becomes opt-out on Fennec).

> > - That said, if Telemetry is the future direction of data collection, would
> > seem to make sense to "simply" add the hardware collection items to an
> > opt-out whitelist or other way to make sure we gather from the larger
> > audience.
> 
> That sounds like Unified Telemetry anyway.
> 
> > - Key question: if collecting this hardware data in an opt-out manner using
> > Telemetry is tied to "future direction of mobile measurement", how far off
> > is this? Right now the games program "big bang" (new brand/website/data
> > being published) is coalescing around March of 2016. Would hope to have
> > initial data flowing several months before so we could tune/tweak before
> > publishing.
> 
> The Mobile team needs some support from the Telemetry team to make it
> happen. Mobile alone does not have the bandwidth or domain knowledge to
> handle it completely.

There is a syncup meeting later today between measurement and mobile, maybe we can find out the status there?

0: https://gecko.readthedocs.org/en/latest/toolkit/components/telemetry/telemetry/environment.html

Comment 13

[Georg Fritzsche [:gfritzsche]]

Per yesterdays meeting, (Unified) Telemetry will probably be the way forward on Fennec and FHR will go away.
We shouldn't invest in adding things to FHR on Fennec anymore.

So we should add the metrics here to Telemetry.

Comment 14

[Jamie Nicol [:jnicol]]

From what I can tell there are no APIs available on Android to provide this information. Which means we need to parse /proc/cpuinfo. Also from what I can tell, ARM CPUs do not have the same notions of "vendor", "family", and "stepping", as x86 CPUs. /proc/cpuinfo therefore looks very different on ARM.

What it contains instead are "CPU implementer", "CPU variant", "CPU architecture", "CPU part", and "CPU revision".

I think "CPU implementer" is roughly equivalent to "vendor" (though it is a number rather than a string. 0x41 = ARM, 0x51 = Qualcomm, etc).
"CPU part" could be used as "family". Again this is a number, eg 0xC0F = Cortex A15.
"CPU variant" and "CPU revision" together could be used as stepping, I believe. If variant is 0 and revision is 2, then that's "r0p2" in the naming scheme ARM uses for processor revisions.

(source for above info: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0438d/BABCBFDF.html)

Does the above look like the right information to use?

Now of course Android !=> ARM, or vice versa. I would presume that the Android x86 code could use the current linux implementation, and that when on ARM, Linux should use what's described above. But I have neither an x86 Android device nor an ARM Linux device to confirm that.

Comment 15

[Milan Sreckovic [:milan] (needinfo for best results)]

As long as we have the decoder ring to figure out what the incoming telemetry information means, and we are consistent, it should be fine to capture this information any way we want to.  Your suggestions above thus sound quite reasonable to me.

Comment 16

[Georg Fritzsche [:gfritzsche]]

Andre, i see this doesn't depend on any open bugs now.
Is this done or is there anything left to do here?

Comment 17

[Andre Vrignaud [:andre] [Seattle - PST]]

We are finding out right now. Just met with Rebecca yesterday, and she's working on getting an initial pull of data so we can make sure we're getting everything we need and if we are missing anything. Anthony Vaughn, our new games PM, is going to birddog this process, and is working on a proposed report structure now (high-level - think something we can give web agency so they have a guide on what to build). That structure is what Rebecca will pull against. 

For now, should leave this open until we verify we're getting all/correct data in Rebecca's test.

Comment 18

[Chris H-C :chutten]

Our future path for Android is glean support on Fenix, so we're unlikely to tackle this.