[minutes] 20110824 Web Performance WG Teleconference #47

Meeting Summary:



1.      Discussed Status for Timing Specifications.

a.       Discuss sub-millisecond timestamp resolution

The Timing specifications currently only provide millisecond resolution from the Unix epoch offset. Sub-millisecond resolution may be desired for User Timing, and possibly future Graphics Timings, in order to precisely calculate framerates and other measurements. Considering, the Timing specifications use a monotonic clock, using a different timebase than Date.now() should not raise a conflict, as the two shouldn't be compared anyway.



We are proposing that all timing attributes returned from the new getEntries() methods be defined in sub-millisecond resolution in terms of a monotonic clock measuring time elapsed from the beginning of the navigation of the root document (navigationStart). In order to preserve compatibility of performance.timing (Navigation Timing), getting timing attributes directly from performance.timing will continue to return millisecond resolution from the Unix epoch.



b.       Statistical Fingerprinting thread

The WG has not yet directly responded to the statistical fingerprinting question raised on the on the mailing list - http://lists.w3.org/Archives/Public/public-web-perf/2011May/0102.html. Considering both the IE and Chrome security teams have reviewed this issue, both Jatinder and Tony will respond to the thread with their findings (which have been discussed in other threads).



Detailed Notes:



Web Perf Teleconference #47 8/24/2011



IRC log: http://www.w3.org/2011/08/24-webperf-irc


Meeting Minutes: http://www.w3.org/2011/08/24-webperf-minutes.html



Attendees

Present for Navigation Timing, Resource Timing and User Timing (4-5PM EST/1-2PM PST)
Tony Gentilcore, James Simenson, Jatinder Mann, Nic Jansma, Arvind Jain, Zhiheng Wang, Karen Anderson


Present for Page Visibility, Efficient Script Yielding, Display Paint Notifications (4-5PM EST/2-3PM PST)
Meeting cancelled.



Scribe

Jatinder Mann



Contents

Agenda

1.       Discuss microsecond timestamp resolution.

2.       Discuss other Timing spec feedback.

3.       Any other business.



--------------------------------------------------------------------------------
Discuss microsecond timestamp resolution.
Jatinder: The problem is we may want to provide sub-millisecond resolution for scenarios where microsecond solution is wanted, like graphics frame rate calculation. Microsecond resolution may not be necessary be for Navigation or Resource Timing, but may be needed for User and future timings like Graphics.
JamesS: Based on the mailing list conversation, seeing that we have a monotonic clock, people shouldn't be comparing with Date.now(), so I think that argument shouldn't be used.
Jatinder: Yes, that is a good point. The two shouldn't be compared based on that reason.
Nic: But we have shipped Navigation Timing? We wouldn't want to break compatibility if we change the offset?
JamesS: We can report microsecond resolution without the unix epoch offset when using getEntries() method but return the current millisecond unix epoch offset when looking at performance.timing directly.
Nic: That is a potential compromise.
Zhiheng: Do we need microsecond resolution for Navigation or Resource Timing?
JamesS: We could spec it out that the NT or RT can round up to millisecond resolution if the UA wants.
Zhiheng: Makes sense.
Nic: So long long or double?
JamesS: We should stick with double and not deal with this problem again.
Jatinder: And the double would be offset from the navigationStart from root document?
JamesS: Correct.
... We should probably also change the Monotonic Clock to not use unix epoch.
... We still need to respond to the finger printing email.
Tony: What was our planned response? Is it that there is no privacy concern or that the privacy concern isn't any worse then it is today?
Nic: To paraphrase, our findings were that the privacy concern wasn't any worse then it is today with what you can do with the onload events.
Jatinder: We should take an action to both respond to that email thread with our findings.