Closed
Bug 1334515
Opened 8 years ago
Closed 7 years ago
Breakdown of work for addons recording events
Categories
(Toolkit :: Telemetry, defect, P1)
Toolkit
Telemetry
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox54 | --- | affected |
People
(Reporter: gfritzsche, Assigned: gfritzsche)
References
(Blocks 1 open bug)
Details
(Whiteboard: [measurement:client])
While we already have bugs filed on Event Telemetry for addons, we need to re-check if that planning is complete & up-to-date.
Assignee | ||
Updated•8 years ago
|
Priority: P1 → P3
Assignee | ||
Updated•8 years ago
|
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → gfritzsche
Priority: P2 → P1
Assignee | ||
Comment 1•7 years ago
|
||
I have the plan for Q2 laid out here:
https://docs.google.com/document/d/1riRfomU_EJfsekKveRwzArKH5sqfr4U6RHf1hwzdoMA/
Next is clearing the last open questions and re-checking bugs, filing new ones where needed.
Assignee | ||
Updated•7 years ago
|
Priority: P1 → P3
Assignee | ||
Updated•7 years ago
|
Priority: P3 → P1
Assignee | ||
Comment 2•7 years ago
|
||
Mossop, Mathieu, your names were mentioned for Kinto client integration and clock skew.
From what gather, "services.blocklist.clock_skew_seconds" is something that i could hang client logic off?
https://dxr.mozilla.org/mozilla-central/search?q=blocklist+clock_skew_seconds&redirect=true
Is that true?
And what are the constraints?
- From when on can i expect this to be set?
- How often is it updated?
- What precision can i expect from it? (A precision in the day range would be sufficient here).
- Can we get a relatively stable clock from it? Or do we only have the clock skew data?
Short context:
I want to be able to expire Telemetry probes on the Firefox client automatically by date, but client clocks are not reliable enough for that.
If there is a sufficiently reliable client clock solution, i could compare expiry dates for Telemetry probes against it.
Flags: needinfo?(mathieu)
Flags: needinfo?(dtownsend)
Updated•7 years ago
|
Flags: needinfo?(dtownsend)
Comment 3•7 years ago
|
||
Hi!
This clock skew is indeed something that is updated when the blocklists are updated. AFAIK it is used for certificates expiration. :mgoodwin was the original author :)
> could hang client logic off?
Yes, I believe so. Mark could confirm.
> And what are the constraints?
Apart from the fact that it has no value on empty profiles, and it's very low update frequency, I don't see many more specific constraints.
> - From when on can i expect this to be set?
It will be set after the first blocklist service notify(). I don't have the exact information about when it is triggered for the first time.
> - How often is it updated?
It is updated along with the blocklist service notify(): AFAIK every 24H
> - What precision can i expect from it? (A precision in the day range would be sufficient here).
It's the difference between settings server time and local time in seconds.
> - Can we get a relatively stable clock from it? Or do we only have the clock skew data?
We only store the difference in that preference. You could build a clock on top of it I guess.
I hope I gave you some insights. Let's see if Mark has more details to share :)
Flags: needinfo?(mathieu) → needinfo?(mgoodwin)
Comment 4•7 years ago
|
||
So Matt's covered all of the important points. The update frequency is probably less of an issue than the fact that it's not hugely accurate; due to CDN constraints, the skew value could be out by a few hours. That said, it's still fine for use in (coarse) expiry calculations and the like.
(In reply to Mathieu Leplatre (:leplatrem) from comment #3)
> > could hang client logic off?
>
> Yes, I believe so. Mark could confirm.
Yes. We are doing just that.
Flags: needinfo?(mgoodwin)
Assignee | ||
Comment 5•7 years ago
|
||
Thanks Mathieu & Mark!
I'm tracking the clock-specific part out to bug 1367366.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•