Closed Bug 1385366 Opened 3 years ago Closed 3 years ago
Since Last Ping in BHR ping payload
I think I'm going to use a normal uptime rather than the "bhr-visible" time as what exactly that should look like is a little confusing considering that there is technically a different sense of bhr-visible time in each process. Will that be OK for hangs.html dthayer?
Yeah I'm fine with that.
Summary: Include BHR-visible usage time in the bhr ping → Include timeSinceLastPing in BHR ping payload
This is the simplest way I could think of to add this data to the payloads for dthayer's hangs.html. data-r?rweiss
:mystor, can you attach a file to this bug with your answers to the questions located in this doc (https://docs.google.com/document/d/1SSn5w8DfCSkHWJS8DNTd7ya82diWRxaDUFM5aL4UDDo/edit)? (New review process we're testing).
(In reply to Rebecca Weiss from comment #4) > :mystor, can you attach a file to this bug with your answers to the > questions located in this doc > (https://docs.google.com/document/d/ > 1SSn5w8DfCSkHWJS8DNTd7ya82diWRxaDUFM5aL4UDDo/edit)? (New review process > we're testing). I can, but it seems like it's a bit overkill for this bug. This bug just adds a number to the ping representing the real time which has passed since the last BHR ping was sent, and we want to use it in order to be able to get a estimation of how frequently we're hanging.
Flags: needinfo?(michael) → needinfo?(rweiss)
I understand it may be overkill. FWIW, I will be replying with this form (https://docs.google.com/document/d/1QK3agapcFsyNRGg4DeW8IqkICkrA83ot-BJeZIkOTwE/edit). If I have your answers to those 8 questions available, I can fill out the form much faster and clear the data review very quickly. If one of those 8 questions doesn't apply to your situation, you can indicate it with an -n/a- response.
Flags: needinfo?(rweiss) → needinfo?(michael)
Comment on attachment 8901311 [details] [diff] [review] Include timeSinceLastPing in BHR ping payload Review of attachment 8901311 [details] [diff] [review]: ----------------------------------------------------------------- I have no objections to the technical side of things.
Attachment #8901311 - Flags: review?(nfroyd) → review+
-- Request For Data Collection -- 1) What are the motivating questions you want to answer with this data? We would like to know the rate at which hangs occur within the browser compared to usage time. 2) Why does Mozilla need answers to this question? Are there benefits for users? Do we need this information to address business requirements? This information can be used to establish baseline knowledge about the rate at which hangs occur in firefox. 3) List all proposed measurements High-level Description | Measurement Type | Tracking Bug # ========================================================== Time since last `bhr` ping | Technical Data | 1385366 4) How long will this data be collected? This information will become part of the default bhr ping, which currently has no known end date, and is part of the BHR project. I am the contact for this ping. 5) What populations do you need to do these measurements for? We're collecting this information from all users on the nightly channel. We currently have no plans to expand BHR data collection out of the nightly channel. 6) Please provide a general description of how you will analyze this data. We will use this data in :dthayer's interface to calculate the rate of hangs per usage hour, and hang time per usage hour of various types of hangs. This will help us measure the severity of various hangs. 7) What alternative methods did you consider to answer this question? Why were they not sufficient? We're actively performing profiles of local copies of firefox, but this has not proved sufficient to improve input latency metrics. BHR is a project to try to collect more actionable data about the hangs which occur while running firefox. 8) Can current instrumentation answer this question? When BHR data was in the main ping we had this information, but it has been moved into a separate ping and now we no longer have this data being collected. 9) Where do you intend to share the results of your analysis? http://squarewave.github.io/
Flags: needinfo?(michael) → needinfo?(rweiss)
r+ 1) Is there documentation that describes the schema for the ultimate data set available publicly, complete and accurate? (see here, here, and here for examples) Yes, see bug 1385366 2) Is there a control mechanism that allows the user to turn the data collection on and off? (Note, for data collection not needed for security purposes, Mozilla provides such a control mechanism) Yes, this appears to use a custom ping, which would suggest that it follows the opt-out mechanism in privacy preferences. 3) If the request is for permanent data collection, is there someone who will monitor the data over time? Yes, :mystor 4) Using the category system of data types on the Mozilla wiki, what collection type of data do the requested measurements fall under? Category 1 5) Is the data collection default-on or default-off? Default on in nightly, not in release. 6) Does the instrumentation include the addition of any new identifiers (whether anonymous or otherwise; e.g., username, random IDs, etc. See the appendix for more details)? No. 7) Is the data collection covered by the existing Firefox privacy notice? Yes 8) Does there need to be a check-in in the future to determine whether to renew the data? ( No
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/bb381b8be26f Include timeSinceLastPing in BHR ping payload, data-r=rweiss, r=froydnj
Comment on attachment 8901311 [details] [diff] [review] Include timeSinceLastPing in BHR ping payload Review of attachment 8901311 [details] [diff] [review]: ----------------------------------------------------------------- reviewed in a different comment.
Attachment #8901311 - Flags: review?(rweiss) → review+
You need to log in before you can comment on or make changes to this bug.