Proposal: clock-drift correction, potentially with opt-in

[noamr]

The problem:

The monotonic clock is accurate for short measurements. But as time goes by, e.g. in long-session web apps, it slowly starts to be less and less aligned with the wall clock. The problem exacerbates when the system throttles or pauses the monotonic clock when a process sleeps. This means that the equation performance.timeOrigin + performance.now() === new Date() becomes less and less reliable over time.

See w3c/hr-time#141 and several related discussions.

The proposal:

Compute a clock offset value per performance entry, at the time of adding the entry to the timeline. This would be something along the lines of clockOffset = new Date() - performance.timeOrigin - performance.now(). This value can help produce wall-clock-aligned timeline out of the standard monotonic-based timeline. The differences between values inside an entry would remain monotonically aligned with each other.
This keeps the benefit of monotonic clocks: accurate offsets, while mitigating the main issue with it: drift from the wall clock.

We can use this offset in several ways, that are somewhat interchangeable/bikesheddable:

1. Add a clockOffset or drift or so to performance timeline entries and let users of the API correct the clocks themselves if they wish.
2. Automatically align entries to the wall clock (while maintaining purely monotonic deltas inside an entry)
3. Make this an opt-in for getEntries{ByFoo} functions or for performance observers.

/cc @yoavweiss @jyasskin @nicjansma

[yoavweiss]

That's interesting!! I wonder if (2) is feasible without creating confusion if/when folks compare timestamps across different entries. Or should we provide helpers for such cross-entry comparisons?

(1) would offload the complexity of dealing with these 2 different clocks to users, but maybe that's ok, as most users don't care about wallclock offsets (although arguably, maybe they should).

[noamr]

That's interesting!! I wonder if (2) is feasible without creating confusion if/when folks compare timestamps across different entries. Or should we provide helpers for such cross-entry comparisons?

I think the main issue with (2) is that it would stop correlating with other things like the devtools and perfetto timelines.
For overlapping entries I'm less concerned because it's usually short timespans where the drift is not significant.

(1) would offload the complexity of dealing with these 2 different clocks to users

Doesn't (3) address this? Users would opt-in to align to the wall clock for a particular query.

[jyasskin]

Is there a reason to report the clock offset instead of the wall clock time of the performance entry? I suspect developers will mix up the sign of an offset.

The rate at which client machines' time drifts is probably useful for fingerprinting, but I think developers can already compute that by just calling Date.now() themselves.

[noamr]

Is there a reason to report the clock offset instead of the wall clock time of the performance entry? I suspect developers will mix up the sign of an offset.

Either is fine. All those values derive from each other, we can choose what to expose.

The rate at which client machines' time drifts is probably useful for fingerprinting, but I think developers can already compute that by just calling Date.now() themselves.

Yes, it's exactly like looking at performance.now() - Date.now() over time manually.
What would help with fingerprinting is fixing this on the hr-time level where the monotonic clock tries to do this automatically and not expose the system's monotonic clock value.

[i-m-abbhay]

Are there any examples or use cases where the clock offset value has been implemented and used effectively?

[Forchapeatl]

@noamr , May I please, handle this issue ? Or has it been reserved for the GSOC 2023 Contribution period ?

[noamr]

@noamr , May I please, handle this issue ? Or has it been reserved for the GSOC 2023 Contribution period ?

Give it a shot! When it's time to pick GSoC projects we can see how far along you are.

[Forchapeatl]

For more time precision over task which take long amount of time to perform (long session web apps),
A developer may compute a more accurate monotonic time by adding the performance.now() to the performance.timeOrigin attribute.

            var mark_start = performance.timeOrigin + performance.now();
            doTask(); // Some task
            var duration = performance.timeOrigin + performance.now() - mark_start;  

Hello @noamr , please am I on the right track here ?

[noamr]

For more time precision over task which take long amount of time to perform (long session web apps), A developer may compute a more accurate monotonic time by adding the performance.now() to the performance.timeOrigin attribute.

            var mark_start = performance.timeOrigin + performance.now();
            doTask(); // Some task
            var duration = performance.timeOrigin + performance.now() - mark_start;  

Hello @noamr , please am I on the right track here ?

Hmm not really :)
The above wouldn't give you different results from simply using entry.duration.

I wouldn't use the term more accurate when it comes to clocks.
"More accurate" is context-specific, as in, which clocks are you trying to compare? Entries to each other? Entries to entries in a different timeline? Entries to the time in UTC?

The current situation is that when we start a window, we start a new "monotonic clock session". Think of it as flipping an hourglass. Within that session, comparisons are accurate enough. But when you want to compare it to session started in other windows, you have to synchronize them somehow. A lot of this is written in the OP...

[Forchapeatl]

Thank you @noamr , I find it difficult to contextualize the expected result. Please are we talking of w3c/performance-timeline or w3c/hr-time/ , may I have some documentation on how these two are related ?

A lot of this is written in the OP

Please , is the OP some documentation ?

In essence , the clock-drift correction , is the comparison between multiple clock sessions on different windows ?

[noamr]

The OP means "the original post" (the description of this issue).
"the comparison between multiple clock sessions on different windows" is part of the problem.

[Forchapeatl]

okay , thank you

[noamr]

Thank you @noamr , I find it difficult to contextualize the expected result. Please are we talking of w3c/performance-timeline or w3c/hr-time/ , may I have some documentation on how these two are related ?

Sorry, I just saw that I only answered the second part.
The two issues are related. It's not too simple!
The main problem is that we're trying to synchronize two inaccurate clocks, in different contexts.
What I'm proposing here is to fix this on the timeline level rather than the clock level: give people who use the timelime indication of the clock-drift, and perhaps helpers to correct the drift in a way that fits their expectations, rather than try to adjust the clock.

[GarretTomlin]

To correct the clock drift issue, I propose computing the clock offset value per performance entry, as suggested in the discussion. This value can be computed as follows

clockOffset = new Date() - performance.timeOrigin - performance.now();

This value can be added as a property to performance timeline entries, allowing users of the API to correct the clocks themselves if they wish. Additionally, the clock offset value can be used to automatically align entries to the wall clock, while maintaining purely monotonic deltas inside an entry.

To implement this, I suggest creating a new performanceEntry object that includes the clockOffset property. This object can be created when a new performance entry is added to the timeline, and the clockOffset property can be set using the above formula. This performanceEntry object can then be added to the timeline as usual.

I also suggest making this an opt-in for getEntries{ByFoo} functions or for performance observers. This will give users the choice to align their entries to the wall clock or not.

I believe this approach is straightforward and easy to implement. It offloads the complexity of dealing with the two different clocks to users while still providing the option to align entries to the wall clock if desired. I plan to use this approach as part of my Google Summer of Code proposal for clock-drift correction. Any feedback would be greatly appreciated thank you

[noamr]

Hi Garret, thanks for your proposal and for your interest in this issue!

To correct the clock drift issue, I propose computing the clock offset value per performance entry, as suggested in the discussion. This value can be computed as follows

clockOffset = new Date() - performance.timeOrigin - performance.now();

This value can be added as a property to performance timeline entries, allowing users of the API to correct the clocks themselves if they wish. Additionally, the clock offset value can be used to automatically align entries to the wall clock, while maintaining purely monotonic deltas inside an entry.

To implement this, I suggest creating a new performanceEntry object that includes the clockOffset property. This object can be created when a new performance entry is added to the timeline, and the clockOffset property can be set using the above formula. This performanceEntry object can then be added to the timeline as usual.

Wouldn't this double the amount of entries in the timeline though?