Re: Timing API issues with wall-clock time

Hi, Jatinder,

   The new text looks good and is more concise.

   I have some other thoughts about making it normative though. Please find
comments inline.

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.
>

   As long as an implementation conforms to other parts of the spec, this is
guaranteed to be true? If so, does it still matter if this sentence is
normative?



> 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.
>

    This is more related to implementation details. We could make it
normative. Then if, in the future, a user agent comes up with a new and
monotonic wall clock and
uses it to implement this spec, the implementation will be non-conformance
in theory even though the interface will work exactly the same.

    I completely agree this is an important aspect but wonder if there is an
alternative than making it normative.

cheers,
Zhiheng



> 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
>
>
>