- From: Christian Biesinger <cbiesinger@gmail.com>
- Date: Mon, 25 Apr 2011 10:51:13 -0700
- To: Jatinder Mann <jmann@microsoft.com>
- Cc: Zhiheng Wang <zhihengw@google.com>, Nic Jansma <Nic.Jansma@microsoft.com>, James Simonsen <simonjam@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, "public-web-perf@w3.org" <public-web-perf@w3.org>
I support making this a normative paragraph. Seems valuable to be able to rely on this in all UAs. -christian On Mon, Apr 25, 2011 at 10:33 AM, Jatinder Mann <jmann@microsoft.com> wrote: > Thanks Zhiheng for making this change, > http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#mono-clock. > We would like to suggest a simplification of the two paragraphs: > > > > Section 5.3 The Monotonic Clock > > > > The value of the timing attributes must monotonically increase to ensure > timing attributes are not skewed by adjustments to the system clock during > the navigation. The difference between any two chronologically recorded > timing attributes must never be negative. The user agent must record the > system time at the beginning of the navigation and define subsequent timing > attributes in terms of a monotonic clock measuring time elapsed from the > beginning of the navigation. > > Considering the value of consistent timing data amongst user agents, we > recommend making this text normative. Thoughts? > > Thanks, > > Jatinder > > > > From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] > On Behalf Of Zhiheng Wang > Sent: Tuesday, April 12, 2011 4:36 PM > To: Nic Jansma > Cc: James Simonsen; Boris Zbarsky; public-web-perf@w3.org > > Subject: Re: Timing API issues with wall-clock time > > > > We can add a new section 4.7 for this. It would probably be non-normative > recommendation. > > > > Oh, yes, I am also in favor of Boris' proposal of having a wall-clock + > monotonic clock solution. > > > > cheers, > > Zhiheng > > > > On Tue, Apr 12, 2011 at 3:20 PM, Nic Jansma <Nic.Jansma@microsoft.com> > wrote: > > IE currently calculates the timestamps as Boris describes. > > > > We'd support a change in the spec to recommend this approach, though picking > simple wording to describe it may be tricky. > > > > - Nic > > > > From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] > On Behalf Of James Simonsen > Sent: Tuesday, April 12, 2011 2:28 PM > To: Boris Zbarsky > Cc: public-web-perf@w3.org > Subject: Re: Timing API issues with wall-clock time > > > > On Tue, Apr 12, 2011 at 1:47 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > > On the other hand, an issue with monotonic clocks is that you can't really > use them to record "the time right now" except in some sort of opaque > timestamp format. They're very good for measuring time intervals, of > course. Are people ok with exposing opaque timestamps (that can't > necessarily be converted to wall-clock time, etc) to JS? > > > > A few of us had a brief discussion about it at lunch today and everyone > seemed to like it. People were using the terms "monotonic clock" and > "document time." > > > > For the particular case of navigation timing one possibility is that the > page load start is recorded as wall-clock epoch time and the other times > reported by the interface are defined in terms of a monotonic clock > measuring time elapsed from the page load start. That would be > API-compatible with the existing spec, I think, but ensure that the > differences between the reported numbers actually correspond to elapsed > durations. > > > > That should be pretty safe for Navigation Timing, since all of the times > should be relatively close to the epoch time. I'm a little more concerned > about Resource Timing and User Timing, particularly on long running apps > like e-mail. The values returned by the API and the values returned by Date > could diverge quite a bit. For the longer lasting APIs, I think we need to > make it more clear we're using a monotonic clock. And it'd be nice to use > the same solution for all 3 timing APIs. > > > > James > >
Received on Monday, 25 April 2011 17:51:41 UTC