Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix timestamp definition to align with webrtc-stats #3005

Merged
merged 5 commits into from
Oct 3, 2024

Conversation

henbos
Copy link
Contributor

@henbos henbos commented Sep 19, 2024

Fixes #3004


Preview | Diff

@jan-ivar
Copy link
Member

Not editorial IMHO, so you'll need to do an amendment

@henbos
Copy link
Contributor Author

henbos commented Sep 24, 2024

aarongable pushed a commit to chromium/chromium that referenced this pull request Sep 27, 2024
For w3c/webrtc-pc#3005

Sadly Date.now() and performance.timeOrigin + performance.now() only
diverge in edge cases (e.g. laptop going to sleep or wall clock
changing while web page is still open?) so these WPTs may give false
positives to Wall Clock implementations, but they will at least
fail if clock is completely off and document correct behavior.

The current implementation is wrong, but we still pass the test because
of no divergence here. We need to exclude Windows at the moment though
because some of its clocks has precision limitations (example: [1]) and
there seems to be some mismatch between WebRTC's current clock impl and
Performance that becomes visible in this WPT (just a few ms delta).

[1] https://source.chromium.org/chromium/chromium/src/+/main:base/time/time.h;l=1180;drc=1a6106ec2fc932237359fe1f54334a66bc4886f1

Bug: chromium:369369568
Change-Id: Iad452519800aa4c41427317d29e4fb11235b2f37
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5887191
Commit-Queue: Henrik Boström <[email protected]>
Reviewed-by: Harald Alvestrand <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1361140}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Sep 27, 2024
For w3c/webrtc-pc#3005

Sadly Date.now() and performance.timeOrigin + performance.now() only
diverge in edge cases (e.g. laptop going to sleep or wall clock
changing while web page is still open?) so these WPTs may give false
positives to Wall Clock implementations, but they will at least
fail if clock is completely off and document correct behavior.

The current implementation is wrong, but we still pass the test because
of no divergence here. We need to exclude Windows at the moment though
because some of its clocks has precision limitations (example: [1]) and
there seems to be some mismatch between WebRTC's current clock impl and
Performance that becomes visible in this WPT (just a few ms delta).

[1] https://source.chromium.org/chromium/chromium/src/+/main:base/time/time.h;l=1180;drc=1a6106ec2fc932237359fe1f54334a66bc4886f1

Bug: chromium:369369568
Change-Id: Iad452519800aa4c41427317d29e4fb11235b2f37
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5887191
Commit-Queue: Henrik Boström <[email protected]>
Reviewed-by: Harald Alvestrand <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1361140}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this pull request Sep 27, 2024
For w3c/webrtc-pc#3005

Sadly Date.now() and performance.timeOrigin + performance.now() only
diverge in edge cases (e.g. laptop going to sleep or wall clock
changing while web page is still open?) so these WPTs may give false
positives to Wall Clock implementations, but they will at least
fail if clock is completely off and document correct behavior.

The current implementation is wrong, but we still pass the test because
of no divergence here. We need to exclude Windows at the moment though
because some of its clocks has precision limitations (example: [1]) and
there seems to be some mismatch between WebRTC's current clock impl and
Performance that becomes visible in this WPT (just a few ms delta).

[1] https://source.chromium.org/chromium/chromium/src/+/main:base/time/time.h;l=1180;drc=1a6106ec2fc932237359fe1f54334a66bc4886f1

Bug: chromium:369369568
Change-Id: Iad452519800aa4c41427317d29e4fb11235b2f37
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5887191
Commit-Queue: Henrik Boström <[email protected]>
Reviewed-by: Harald Alvestrand <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1361140}
@henbos henbos merged commit 0a51ae3 into w3c:main Oct 3, 2024
3 checks passed
dontcallmedom added a commit that referenced this pull request Oct 3, 2024
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this pull request Oct 8, 2024
…essed in "Performance time"., a=testonly

Automatic update from web-platform-tests
Add WPTs that RTCStats.timestamp is expressed in "Performance time".

For w3c/webrtc-pc#3005

Sadly Date.now() and performance.timeOrigin + performance.now() only
diverge in edge cases (e.g. laptop going to sleep or wall clock
changing while web page is still open?) so these WPTs may give false
positives to Wall Clock implementations, but they will at least
fail if clock is completely off and document correct behavior.

The current implementation is wrong, but we still pass the test because
of no divergence here. We need to exclude Windows at the moment though
because some of its clocks has precision limitations (example: [1]) and
there seems to be some mismatch between WebRTC's current clock impl and
Performance that becomes visible in this WPT (just a few ms delta).

[1] https://source.chromium.org/chromium/chromium/src/+/main:base/time/time.h;l=1180;drc=1a6106ec2fc932237359fe1f54334a66bc4886f1

Bug: chromium:369369568
Change-Id: Iad452519800aa4c41427317d29e4fb11235b2f37
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5887191
Commit-Queue: Henrik Boström <[email protected]>
Reviewed-by: Harald Alvestrand <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1361140}

--

wpt-commits: e093609edda48c99f0951bf5862664dc58fd1a70
wpt-pr: 48361
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this pull request Oct 9, 2024
…essed in "Performance time"., a=testonly

Automatic update from web-platform-tests
Add WPTs that RTCStats.timestamp is expressed in "Performance time".

For w3c/webrtc-pc#3005

Sadly Date.now() and performance.timeOrigin + performance.now() only
diverge in edge cases (e.g. laptop going to sleep or wall clock
changing while web page is still open?) so these WPTs may give false
positives to Wall Clock implementations, but they will at least
fail if clock is completely off and document correct behavior.

The current implementation is wrong, but we still pass the test because
of no divergence here. We need to exclude Windows at the moment though
because some of its clocks has precision limitations (example: [1]) and
there seems to be some mismatch between WebRTC's current clock impl and
Performance that becomes visible in this WPT (just a few ms delta).

[1] https://source.chromium.org/chromium/chromium/src/+/main:base/time/time.h;l=1180;drc=1a6106ec2fc932237359fe1f54334a66bc4886f1

Bug: chromium:369369568
Change-Id: Iad452519800aa4c41427317d29e4fb11235b2f37
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5887191
Commit-Queue: Henrik Boström <hboschromium.org>
Reviewed-by: Harald Alvestrand <htachromium.org>
Cr-Commit-Position: refs/heads/main{#1361140}

--

wpt-commits: e093609edda48c99f0951bf5862664dc58fd1a70
wpt-pr: 48361

UltraBlame original commit: ca92ef355a24e10b5b143cb4056ac1c30c06c18b
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this pull request Oct 9, 2024
…essed in "Performance time"., a=testonly

Automatic update from web-platform-tests
Add WPTs that RTCStats.timestamp is expressed in "Performance time".

For w3c/webrtc-pc#3005

Sadly Date.now() and performance.timeOrigin + performance.now() only
diverge in edge cases (e.g. laptop going to sleep or wall clock
changing while web page is still open?) so these WPTs may give false
positives to Wall Clock implementations, but they will at least
fail if clock is completely off and document correct behavior.

The current implementation is wrong, but we still pass the test because
of no divergence here. We need to exclude Windows at the moment though
because some of its clocks has precision limitations (example: [1]) and
there seems to be some mismatch between WebRTC's current clock impl and
Performance that becomes visible in this WPT (just a few ms delta).

[1] https://source.chromium.org/chromium/chromium/src/+/main:base/time/time.h;l=1180;drc=1a6106ec2fc932237359fe1f54334a66bc4886f1

Bug: chromium:369369568
Change-Id: Iad452519800aa4c41427317d29e4fb11235b2f37
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5887191
Commit-Queue: Henrik Boström <hboschromium.org>
Reviewed-by: Harald Alvestrand <htachromium.org>
Cr-Commit-Position: refs/heads/main{#1361140}

--

wpt-commits: e093609edda48c99f0951bf5862664dc58fd1a70
wpt-pr: 48361

UltraBlame original commit: ca92ef355a24e10b5b143cb4056ac1c30c06c18b
i3roly pushed a commit to i3roly/firefox-dynasty that referenced this pull request Oct 9, 2024
…essed in "Performance time"., a=testonly

Automatic update from web-platform-tests
Add WPTs that RTCStats.timestamp is expressed in "Performance time".

For w3c/webrtc-pc#3005

Sadly Date.now() and performance.timeOrigin + performance.now() only
diverge in edge cases (e.g. laptop going to sleep or wall clock
changing while web page is still open?) so these WPTs may give false
positives to Wall Clock implementations, but they will at least
fail if clock is completely off and document correct behavior.

The current implementation is wrong, but we still pass the test because
of no divergence here. We need to exclude Windows at the moment though
because some of its clocks has precision limitations (example: [1]) and
there seems to be some mismatch between WebRTC's current clock impl and
Performance that becomes visible in this WPT (just a few ms delta).

[1] https://source.chromium.org/chromium/chromium/src/+/main:base/time/time.h;l=1180;drc=1a6106ec2fc932237359fe1f54334a66bc4886f1

Bug: chromium:369369568
Change-Id: Iad452519800aa4c41427317d29e4fb11235b2f37
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5887191
Commit-Queue: Henrik Boström <[email protected]>
Reviewed-by: Harald Alvestrand <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1361140}

--

wpt-commits: e093609edda48c99f0951bf5862664dc58fd1a70
wpt-pr: 48361
ErichDonGubler pushed a commit to erichdongubler-mozilla/firefox that referenced this pull request Oct 11, 2024
…essed in "Performance time"., a=testonly

Automatic update from web-platform-tests
Add WPTs that RTCStats.timestamp is expressed in "Performance time".

For w3c/webrtc-pc#3005

Sadly Date.now() and performance.timeOrigin + performance.now() only
diverge in edge cases (e.g. laptop going to sleep or wall clock
changing while web page is still open?) so these WPTs may give false
positives to Wall Clock implementations, but they will at least
fail if clock is completely off and document correct behavior.

The current implementation is wrong, but we still pass the test because
of no divergence here. We need to exclude Windows at the moment though
because some of its clocks has precision limitations (example: [1]) and
there seems to be some mismatch between WebRTC's current clock impl and
Performance that becomes visible in this WPT (just a few ms delta).

[1] https://source.chromium.org/chromium/chromium/src/+/main:base/time/time.h;l=1180;drc=1a6106ec2fc932237359fe1f54334a66bc4886f1

Bug: chromium:369369568
Change-Id: Iad452519800aa4c41427317d29e4fb11235b2f37
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5887191
Commit-Queue: Henrik Boström <[email protected]>
Reviewed-by: Harald Alvestrand <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1361140}

--

wpt-commits: e093609edda48c99f0951bf5862664dc58fd1a70
wpt-pr: 48361
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this pull request Oct 15, 2024
…essed in "Performance time"., a=testonly

Automatic update from web-platform-tests
Add WPTs that RTCStats.timestamp is expressed in "Performance time".

For w3c/webrtc-pc#3005

Sadly Date.now() and performance.timeOrigin + performance.now() only
diverge in edge cases (e.g. laptop going to sleep or wall clock
changing while web page is still open?) so these WPTs may give false
positives to Wall Clock implementations, but they will at least
fail if clock is completely off and document correct behavior.

The current implementation is wrong, but we still pass the test because
of no divergence here. We need to exclude Windows at the moment though
because some of its clocks has precision limitations (example: [1]) and
there seems to be some mismatch between WebRTC's current clock impl and
Performance that becomes visible in this WPT (just a few ms delta).

[1] https://source.chromium.org/chromium/chromium/src/+/main:base/time/time.h;l=1180;drc=1a6106ec2fc932237359fe1f54334a66bc4886f1

Bug: chromium:369369568
Change-Id: Iad452519800aa4c41427317d29e4fb11235b2f37
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5887191
Commit-Queue: Henrik Boström <hboschromium.org>
Reviewed-by: Harald Alvestrand <htachromium.org>
Cr-Commit-Position: refs/heads/main{#1361140}

--

wpt-commits: e093609edda48c99f0951bf5862664dc58fd1a70
wpt-pr: 48361

UltraBlame original commit: ca92ef355a24e10b5b143cb4056ac1c30c06c18b
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

RTCStats::timestamp discrepancy between webrtc-stats and webrtc-pc
2 participants