Participants

Yoav Weiss, Jonathan Mayer, Michal Mocny, Nicolás Peña Moreno, Hongbo Song, Andrew Galloni, Sean Feng, Benjamin De Kosnik

Next Meeting

Thursday May 27th, 10am PST / 1pm EST

Minutes

PerfTimeline #181: Should droppedEntriesCount be frozen on each observer? 

• Nicolás: Looking to implementing droppedEntriesCount
• … Surfaces how many dropped entries
• … Is it confusing that the count increases on each callback?
• … Once buffer becomes full, each new entry will increase it even if you’re observing it
• … One potential solution is to freeze the number once it becomes non-zero
• … If it’s not zero in the first callback, you know you missed entries
• … If it becomes non-zero afterwards, you know when the buffer became full.
• … Wondered if people had thoughts?
• Michal: Part of the problem with dropped buffers or cleared buffers, is that there could be different consumers of this API that could register observers at any time
• … If you froze it, it would be the same as the first observer
• Nicolás: I should clarify, it would be frozen for each observer, so different observers could get different numbers
• Michal: Sounds fine.  For event counts we get the total number of events.  Instead of the number of dropped entries, we could give a total, and let developers infer if there were any dropped ones.
• Yoav: What concerned me about current API shape where the number keeps growing over time, is that people will get confused
• … and despite the fact they registered an observer early on, they still have entries being “dropped” (even though they’re observing them)
• … On the consumer’s side of the API, would this be an issue?
• Nic: Agree that if the number would keep growing it could lead to developers being confused about it.
• … Those in the know would get it, but it’d be a gotcha and we’d need to make sure people grok it.
• … Kinda like the idea of it being frozen. In our case we’d only be reading it in the beginning.
• … But I could see someone looking at their callback in devtools and being confused. Haven’t thought through it
• Andrew: I agree, but need to think it through
• Nic: Michal - was your thought of a total count being a global thing available?
• Michal: Calling it numdropped would induce confusion as people would think that more entries were dropped but renaming it to total count would make it clear why the number grows, and we already do this elsewhere.
• … The 2 numbers are equivalent, because you have a fixed buffer size.
• … Could be a case that freezing the number would be confusing as well. A rename can help here as well
• … The advantage of having a dropped vs. total is that a non-zero value means that you have an incomplete observer, where the alternative requires more work, so it’s less obvious.
• Nic: Agree with that
• Michal: So for the specific use case, sounds like fixing it to the number of dropped entries at registration would be best
• Nicolás: Would we freeze it at zero or would it be useful to get a rough estimate of when the buffer became full?
• Nic: So when observers register early and the buffer becomes full later?
• Nicolás: yeah
• Yoav: theoretically, we could a separate method on `performance` to get the number of dropped entries, and decouple it entirely from PerfObserver. But that’d mean we don’t get a signal of when the buffer becomes full. Not sure that’s meaningful.
• Nicolás: It becomes hard to know when you have to query to ensure you’re not missing entries. That’s why coupling it with the observer is useful.
• Michal: If we’re going to freeze the number, is it useful to have a number?
• Nic: It’s useful for RUM, could tell us how many entries we missed - 1000 entries would be a good argument to register earlier. There’s value in knowing the quantity
• Yoav: What I’m hearing is that there’s general support for freezing the value, more than leaving it as is.
• … But the hurdle here is that in terms of shipping, the code is ready, but we don’t want to ship the wrong thing. Wondering what could give us more confidence.
• … Nic and Andrew, can you think about this more and give us an answer?
• Andrew: yeah
• Nic: overall, the value is great. Need to think about the ergonomics. Can definitely think it through.

HR-Time #115: Suggestions: ticking during sleep, comparison across contexts, time origin + now semantics, and skew definition 

• Jonathan: My research group at Princeton is using HRTime for a project that uses timing across web pages
• … Led to rabbit hole around looking at the history of the spec, hardware issues, etc
• … Four suggestions for possible revisions to spec
• … All I hope are very consistent with intent of spec
• … First is to clarify what behavior of what happens during system sleep
• … Second suggestion is to take an informative note (with SHOULD in it) and turning it into normative language.  Turn suspending behavior into normative note, is to accomplish the goal of the spec.  Compare monotonic timestamp across globals.
• … Third suggestion I’ll deal with last
• … In the issue, the fourth suggestion is just a terminology suggestion around “clock skew”, is different from how it’s normally used in computer science or electrical engineering
• … Third suggestion is clarifying semantics if you add performance.timeOrigin with performance.now.  Zero guarantees how that’ll compare to system clock.
• ... But there are some useful properties that could be defined. IIUC, browsers have already implemented the semantics I’m suggesting here, so hopefully it’s just reflecting semantics what browsers already provide rather than changing behavior
• Yoav: Thank you for the issue, it’s well thought-out and articulated.
• … Useful information about various OSs and their clock behaviors
• … Suggestions for clarifying what we do in sleep mode, moving note to normative SHOULD make sense
• … Changing the terminology for clock skew - I think we could align with whatever the rest of the industry uses
• … For the semantics, I’m generally supportive but I wonder if this testable in some way
• … Similarly for sleep, I’m not sure we can have WPT tests for what happens when sleep
• … For semantics, we can’t enforce tests changing the clocks
• … Are there any objections to those clarifications?  What do folks think about testing?
• Nicolás: Only problem is that most clocks seem to be not behaving properly during sleep according to the table.  So the concern is that if we try to change the clocks, if they report internal metrics.  Could risk some breakage.
• Yoav: Do you expect that internal metrics are somehow relying on the fact that the freezing behavior is as it is right now?
• Nicolás: It seems on Windows they don’t rely on it, but I expect some metrics to shift in some ways in particular for high percentiles, because sleeps would count for longer portions of time instead of no portions of time
• Jonathan: How this might be made easier for implementers, rather than changing underlying browser clock implementations, just adding another clock that has well-defined behavior.  
• … Current users of the clock stay in place.  But users that want the definition of the clock that continues during sleep could switch. There’s a Chrome design doc on that, and Firefox has a version of that in place.
• Yoav: That would have a smoother migration process, but I’m not sure it reduces complexity
• Yoav: Benjamin/Sean do you know what the situation is for Mozilla? Can Firefox align with this proposal.
• Benjamin: I think this is doable. Are we talking about adding a performance.now monotonic clock option?
• Yoav: This proposal doesn’t suggest an API change, just changing the semantics of performance.now() would say it SHOULD not freeze when table is throttled or frozen or the system is asleep, so the clock keeps ticking when any of those things happen
• Benjamin: As opposed to not incrementing today?
• Yoav: Current behavior on FF on Linux/Android, but not on Windows/Mac.  Chromium only does that on Windows.  Safari doesn’t do that anywhere.
• Nicolás: It’s already specified, but all browsers are behaving badly.
• Michal: You’re saying there are two clocks in place on some platforms?
• Jonathan: OS tend to provide monotonic multiple clock APIs that vary along at least two axis.  Does the clock tick during system sleep or not?  Is it subject to monotonic adjustments?  
• … For example, your NTP client might figure out it’s off by a bit, can it adjust the clock or not?
• … That’s what OS offer.  With respect to browsers, there’s one monotonic clock implementation across platforms.  Firefox has 2-3 implementations in different places.  One of which gives you the option to call the API with/without sleep included.  Proposal for more implementations in Chrome.
• Benjamin: I’d rather see this fully specified with both options, where it includes with-sleeps or with-adjustments
• Yoav: You want to change the API so that a web developer add options to pick the clock they want?
• Benjamin: What does a web developer get when they use it today, are we going to specify that in the spec?
• Yoav: I’m not sure most web developers would care specifically, unless it’s for detecting sleep
• Nicolás: A while ago we decided sleep needs to tick. What was the reasoning?
• Yoav: It can create a drift compared to date.now, and if we have multiples tabs that are frozen, comparing them can add confusion
• Nicolás: Are these clocks not using a shared infrastructure? Only a system sleep would make them all frozen or not frozen? If it’s possible for clocks to be frozen in some frames but not others, that would mean it’s impossible to compare timestamps across frames.
• Yoav: Issue 65 is mostly around frozen background tabs and clock skew in those cases, didn’t really discuss where the “entire system is in sleep mode” case.
• Jonathan: To answer the question “Could you do this across webpages”, yes.  The way the spec is currently drafted frozen tabs are combined with sleep. We could split the two.
• … I think it might be counterintuitive to have one behavior around frozen tabs vs. system sleep
• … Folks that are really familiar with Date.now() which ticks during sleep, if performance.now() was different could be confusing
• Michal: Date.now() can “teleport”. Would users of Date.now() expect that the two would be in sync?
• Jonathan: Our research group was confused about this.  We thought, barring a user clock change, they’d be close if not identical, and that’s not the case.
• … You may want a timer that is monotonic and roughly approximate to real world time
• … For any precise timestamping of events across webpages that might be useful.
• Yoav: Would be useful to account for time when the tab was frozen or the system was asleep.  For things like user changing their clock there would be a difference between Date.now() and performance.now().  
• … Barring user changing clock, useful if the underlying time would be the same.
• … In my view I don’t see a strong use case to have the ability for web developers to pick the clock options.
• … It would have to be something not on top of performance.now, as it’s used in all the metrics. Maybe we can have a document policy that dictates what clock to use. I don’t necessarily see a strong use case though.
• Jonathan: To add complexity, in addition to performance.now, you’d have to look at .timeOrigin, event.timestamp, etc, to make sure they’re all in sync.
• Benjamin: Wondering if PT#105 might address this
• Yoav: That seems orthogonal. This is a signal on backgrounding status and when tabs where backgrounded. If the clocks were to stop when tabs are backgrounded, that would move a lot of the metrics. Nicolás, the VisibilityObserver effort is on hold, right?
• Nicolás: Yeah, there’s the VisibilityObserver discussion with open questions on prerendering, etc.
• … One reason you’d want clock frozen during sleep if you’re measuring time delta between two events.  Clock would be super-long for no good reason, unless you know the tab froze, which is not something people do.
• … The hidden state may not work in sleep cases.
• Yoav: No strong guarantees that visibility means the tab is frozen. It can be frozen after a timeout, etc. There can be implementation heuristics around that.
• Benjamin: Wondering if there’s an opportunity to address both clarifications and adress unknown timer. Our timers right now are inconsistent when accounting for sleep or frozen times.
• Yoav: Right now we can’t really rely on it because it’s different on different platforms and browsers.  Would like to report timestamps for the time we spent in sleep.  Have a “this tab was frozen” observer, or some indication to know this happened, so people can account for the lost time.
• Benjamin: Add a frozen time to performance entries, or something, mark the gap somewhere in the timeline. Sounds like a good approach.
• Yoav: We could start by aligning all the clocks, but it’d require implementations to do the leg work of implementing it. Appetite may depend on technical complexity. Nicolás says it can get complex, so it may require some more research.
• Nicolás: We could talk to the Chrome folks that wrote the related doc. Good to try to align at least, we all have different behaviors, depending on what’s convenient to do in each OS. Not ideal.
• Jonathan: While on the subject of different behaviors, there’s a deviation in Chrome/Firefox, timeOrigin is set a bit different than the spec.
• Yoav: Useful to file implementation issues on that front
• Jonathan: Filed issue in Chrome and Firefox bug trackers
• Benjamin: If you haven’t already, link to it in the HRTime bug
• Yoav: Thanks! We’re in agreement that it’d be great to make that happen. Now need to figure out how to get there.
• Benjamin: Thanks for normalizing the term “skew”.
• Yoav: Any proposals for other terms we could use.
• Jonathan: “adjustment” would be fine. Giving examples of what’s permitted would help implementers: non-monotonic is not permitted, big adjustments not permitted, monotonic and small/gradual adjustments would be permitted. Just avoid the term “skew”.
• … Would be helpful to have a note on the OS options
• Yoav: That may be useful as a separate document, potentially. I haven’t seen other precedents for implementation hints as spec notes.
• … The issue itself is already useful on that front.