KEMBAR78
timestamp: Redefine timestamp in Data delivery by arskama · Pull Request #274 · w3c/compute-pressure · GitHub
Skip to content

Conversation

arskama
Copy link
Contributor

@arskama arskama commented May 30, 2024

Fixes #257


Preview | Diff

@arskama arskama requested a review from rakuco June 7, 2024 14:09
Signed-off-by: Arnaud Mandy <arnaud.mandy@intel.com>
@arskama arskama requested a review from rakuco June 7, 2024 15:35
Copy link
Member

@rakuco rakuco left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@rakuco rakuco merged commit 1b8a56c into w3c:main Jun 7, 2024
rakuco pushed a commit that referenced this pull request Jun 12, 2024
Follow-up to #274, related to #257.

The call to the "passes rate test" algorithm should use `timeValue` rather
than `timestamp`: the former is what is stored in `PressureRecord.[[Time]]`,
so it makes sense to compare values that have been similarly coarsened and
converted to a relative time.
rakuco pushed a commit that referenced this pull request Jun 12, 2024
Follow-up to #274, related to #257.

The wording used in #274, which mentions platform-specific timestamps, made
more sense in the context of the Generic Sensor API spec, as multiple
platform-specific sensor APIs provide samples with timestamps in a
platform-specific format that needs to be converted.

Of the OS-provided telemetry APIs, however, only Windows optionally provides
samples with a timestamp. As such, it makes more sense to define a timestamp
using the monotonic clock's unsafe current time instead. Aditionally, the
accompanying note was rewritten to indicate that the same value should be
used for all globals, otherwise the same sample would end up with different
"raw" timestamps in different frames/workers.
rakuco pushed a commit that referenced this pull request Jun 13, 2024
…eck (#279)

Follow-up to #274, related to #257.

The call to the "passes rate test" algorithm should use `timeValue` rather
than `timestamp`: the former is what is stored in `PressureRecord.[[Time]]`,
so it makes sense to compare values that have been similarly coarsened and
converted to a relative time.
rakuco pushed a commit that referenced this pull request Jun 13, 2024
Follow-up to #274, related to #257.

The wording used in #274, which mentions platform-specific timestamps, made
more sense in the context of the Generic Sensor API spec, as multiple
platform-specific sensor APIs provide samples with timestamps in a
platform-specific format that needs to be converted.

Of the OS-provided telemetry APIs, however, only Windows optionally provides
samples with a timestamp. As such, it makes more sense to define a timestamp
using the monotonic clock's unsafe current time instead. Aditionally, the
accompanying note was rewritten to indicate that the same value should be
used for all globals, otherwise the same sample would end up with different
"raw" timestamps in different frames/workers.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Is PressureRecord.time a timestamp or a time that is relative to timeOrigin?

2 participants