Provide a way to cross-reference timestamps to monotonic timer
Categories
(Data Platform and Tools :: Glean: SDK, enhancement, P3)
Tracking
(Not tracked)
People
(Reporter: Dexter, Unassigned)
References
Details
(Whiteboard: [telemetry:glean-rs:backlog])
Current glean pings have start_time
and end_time
. The baseline
ping also has the duration
field which says how long the "session" was. We could spread this field to all pings.
Reporter | ||
Updated•6 years ago
|
Comment 1•6 years ago
|
||
start_time
and end_time
are pure client timestamps (subject to all the known problems of skew and user interference and timezone jumping) and duration
is from a monotonic source which is exempt from client clock weirdness but might conceivably have some kind of bug 1204823 style of issue (we don't know yet).
Being able to cross-reference the timekeeping methods against each other would have analysis value. In my opinion.
Reporter | ||
Updated•6 years ago
|
Reporter | ||
Updated•6 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 2•5 years ago
•
|
||
:chutten Agree 100% about the different sources of timing, and the need to cross reference them. However, I'm not sure this will get us what we want in that regard.
The current glean.baseline.duration
value measures the "session length", or the time the browser was in foreground.
start_time
is the start of the ping lifetime, which in the case of the baseline ping actually begins right after the browser goes to background, and the end_time
is set the next time the browser goes to background.
I'm not writing this to be pedantic -- I too was confused by this when I recently tried to see if the discrepancies between these spans could be used to see patterns in why duration was sometimes NULL (bug 1525600).
Beyond that, even if we did change the definition of duration
to match that of start_time
/end_time
and be about ping lifetime, it would be difficult to use a monotonic timer for that, since currently a metrics ping (sent at most one a day) could have a lifetime that extends across reboots, and the monotonic timer is reset across reboots. So we would be forced to using the system clock for that anyway (with all of its known problems) or using some sort of network time as I think as been discussed elsewhere, with all of its complexity.
Comment 3•5 years ago
|
||
(In reply to Michael Droettboom [:mdroettboom] from comment #2)
start_time
is the start of the ping lifetime, which in the case of the baseline ping actually begins right after the browser goes to background, and theend_time
is set the next time the browser goes to background.
Whoa. That's not what I expected. I mean, it makes sense, and is compatible with the definitions laid out in the docs... but for whatever reason I assumed duration would be end_time - start_time
(modulo client clock nonsense).
I'll readjust my mental model. (and this renders comment #1 meaningless). I suppose for pings whose schedules are less than the application lifetime we could have some sort of ping_info.measurement_window_length
or something for cross-reference of client clocks... but that seems like a poor use of resources. A Gleaner way to do it would be to have specific collections and pings for measuring such client clock nonsense.
Reporter | ||
Updated•5 years ago
|
Comment 4•5 years ago
|
||
:chutten: Given all this, I've renamed the bug to describe the problem we're trying to solve rather than any particular solution, and moved this to "incoming" so we'll remember to retriage it at our next meeting.
Reporter | ||
Updated•5 years ago
|
Updated•4 years ago
|
Description
•