Closed Bug 1531783 Opened 6 years ago Closed 4 years ago

Provide a way to cross-reference timestamps to monotonic timer

Categories

(Data Platform and Tools :: Glean: SDK, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX

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.

Priority: -- → P3
Whiteboard: [telemetry:mobilesdk:m?]

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.

Whiteboard: [telemetry:mobilesdk:m?] → [telemetry:mobilesdk:backlog]
Component: Telemetry → Glean: SDK
Product: Toolkit → Data Platform and Tools
Version: Trunk → unspecified
Whiteboard: [telemetry:mobilesdk:backlog] → [telemetry:glean-rs:m?]
Whiteboard: [telemetry:glean-rs:m?] → [telemetry:glean-rs:m8]

: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.

(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 the end_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.

Whiteboard: [telemetry:glean-rs:m8] → [telemetry:glean-rs:m11]

: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.

Summary: Include "duration" in all glean pings → Provide a way to cross-reference timestamps to monotonic timer
Whiteboard: [telemetry:glean-rs:m11] → [telemetry:glean-rs:m?]
Depends on: 1590080
Whiteboard: [telemetry:glean-rs:m?] → [telemetry:glean-rs:backlog]
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.