Summary: | performance.now() does not tick during system sleep | ||
---|---|---|---|
Product: | WebKit | Reporter: | Jonathan Mayer <webkit-bugzilla> |
Component: | Platform | Assignee: | Nobody <webkit-unassigned> |
Status: | NEW --- | ||
Severity: | Normal | CC: | achristensen, ap, cdumez, daxpedda, webkit-bug-importer |
Priority: | P2 | Keywords: | InRadar |
Version: | Safari 14 | ||
Hardware: | Mac (Intel) | ||
OS: | macOS 11 |
Description
Jonathan Mayer
2021-05-10 13:44:52 PDT
Thank you for the super detailed report! Seeing that most browsers are not compliant with this spec change, I'm wondering what the rationale for changing established behavior is. Comparing a monotonic clock to system clock will break once a year in most locations anyway, as the system clock will go backwards. (In reply to Alexey Proskuryakov from comment #1) > Thank you for the super detailed report! > > Seeing that most browsers are not compliant with this spec change, I'm wondering what the rationale for changing established behavior is. Here's the W3C spec discussion: https://github.com/w3c/hr-time/issues/65 A few reasons for consideration: * Consistency with API user expectations, especially since the widely used Date.now() ticks during system sleep. * Consistency across browsers and platforms. * Provides valuable semantics for performance.timeOrigin + performance.now(). Those timestamps will be, within a browsing session: 1) monotonic, 2) comparable across documents, 3) unaffected by major or non-monotonic adjustments to the system clock, and 4) approximately equal to the current time, assuming the system clock was accurate at browser startup. The reason I started digging into this issue is that my academic research group is relying on those very semantics for a project. :) > Comparing a monotonic clock to system clock will break once a year in most locations anyway, as the system clock will go backwards. If you mean leap seconds, I think that's OK. There's no guarantee of how close the monotonic clock and the system clock will be at any particular moment, since the system clock can change at any time. What a browser can guarantee is: 1) the monotonic clock value is approximately equal to the value the system clock would have if it wasn't subject to a major or non-monotonic adjustment after browser startup, and 2) the only other causes of divergence between the monotonic clock and the system clock are a) underlying clock implementation differences (unlikely now, with convergence on invariant TSC for x86 timing and Generic Timers for ARM timing), and b) leap second subtraction or smearing on the system clock (which an API user could account for if necessary by implementing their own leap second subtraction or smearing). I was talking about daylight savings time adjustment. Perhaps you are considering system clock adjusted for that. (In reply to Alexey Proskuryakov from comment #3) > I was talking about daylight savings time adjustment. Perhaps you are > considering system clock adjusted for that. I don't think daylight savings time is an issue, because the system clock (Date.now()) is defined in UTC and UTC doesn't have DST. DST doesn't actually adjust the system clock; it changes the mapping from the system clock to local time (like a time zone). The same mapping can be applied to the monotonic clock if helpful for a use case (new Date(performance.timeOrigin + performance.now())). I was looking into something else and found something related to this problem: Performance::now calls MonotonicTime::now which calls mach_absolute_time. If I understand correctly, this is a request for a timer that uses mach_continuous_time instead. (In reply to Alex Christensen from comment #6) > I was looking into something else and found something related to this > problem: Performance::now calls MonotonicTime::now which calls > mach_absolute_time. If I understand correctly, this is a request for a > timer that uses mach_continuous_time instead. Using clock_gettime / clock_gettime_nsec_np with CLOCK_MONOTONIC might be preferable to CLOCK_MONOTONIC_RAW (which is equivalent to mach_continuous_time). CLOCK_MONOTONIC allows for small monotonic adjustments (e.g., NTP oscillator corrections) and CLOCK_MONOTONIC_RAW doesn't. The result can be an unexpected drift from the system clock. Chrome currently has this very issue (with mach_absolute_time), and in a quick check, I also saw clock drift in Safari on macOS. https://bugs.chromium.org/p/chromium/issues/detail?id=948384 |