RE: Timing API issues with wall-clock time

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<mailto: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> [mailto: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<mailto: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<mailto: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