Re: Comment on High Resolution Time Last Call Draft

Hi Noah,

I don't think that's something we'd want to spec. Browsers, unfortunately,
are highly dependent on the underlying system they run on. We can't
guarantee that every system an HTML5-compatible browser would run on will
be able to provide sufficient resolution to time individual instructions.

Stalling when the clock hasn't advanced would be a no-go. That's bad user
experience.

So, rather than setting such expectations in the spec, and letting web
developers depend on it, we'd rather they just not make such assumptions in
the first place.

I think there could be other solutions for your use cases. For instance,
there should probably be a proper way of getting a unique ID, rather than
inferring it from time. Perhaps you could propose a new spec for that. And
high resolution profiling can be done using developer tools, or by building
a benchmark that runs many iterations.

James

On Tue, Mar 13, 2012 at 10:17 AM, Noah Mendelsohn <nrm@arcanedomain.com>wrote:

> This is a comment on the Last Call Working Draft "High Resolution Time"
> [1].
>
> First of all, thank you for doing this work. Having over a period of many
> years worked on the development of high-performance systems, the
> availability of a monotonic, high resolution (pseudo) clock will be a
> significant improvement to the Web platform IMO.
>
> This specific concern I'd like to raise is with section 4.4 "Monotonic
> clock", which says [2]:
>
> "The time values returned when calling the now method MUST be
> monotonically increasing and not subject to system clock adjustments or
> system clock skew. The difference between any two chronologically recorded
> time values returned from the now method MUST never be negative. "
>
> and section 4.2 which says "4.2 The DOMHighResTimeStamp Type" which says
> [3]:
>
> "Type Definition DOMHighResTimeStamp
>
>    A DOMHighResTimeStamp represents a number of milliseconds accurate to
> at least a tenth of a millisecond."
>
> It's a nice characteristic for high resolution clocks to have sufficient
> resolution that the difference between two successive readings will always
> be positive, never zero. This facilitates the use of such time values for
> the generation of unique timestamps, and also improves their utility for
> timing small amounts of code on high-performance processors.
>
> I know this is an old and obscure reference, but an example of a design
> that attends to this need is the IBM 370 STORE CLOCK instruction, which (as
> documented on page 6 of [4]) is designed always to increment between
> successive stores. The reasons are the same ones described above:
> timestamps can be used as unique identifiers, and the resolution is
> sufficient to provide useful timing even for small amounts of code.
>
> In practice, implementation would require that a browser would have to
> have access to a hardware clock with sufficient resolution, or else (and
> this is a drawback) would have to artificially delay in the case where
> there's a risk of failure to advance.
>
> Anyway, having clocks always move forward between stores is a desirable
> feature. If this is viewed as too aggressive to set as a requirement, I
> would suggest at least the following rewording of the quote from 4.2:
>
> "Type Definition DOMHighResTimeStamp
>
>    A DOMHighResTimeStamp represents a number of milliseconds accurate to
> at least a tenth of a millisecond. Implementations SHOULD provide
> sufficient accuracy that successive accesses to now() will return differing
> values."
>
> Thank you for your consideration of this suggestion. Also: I am speaking
> here for myself, and in particular not for the TAG (which has not
> considered [1]), or for any of the other working groups or organizations
> with which I am affiliated.
>
> Noah
>
>
>
> [1] http://www.w3.org/TR/2012/WD-**hr-time-20120313/
> [2] http://www.w3.org/TR/2012/WD-**hr-time-20120313/#sec-**monotonic-clock
> [3] http://www.w3.org/TR/2012/WD-**hr-time-20120313/#sec-**
> DOMHighResTimeStamp
> [4] http://bitsavers.org/pdf/ibm/**370/princOps/GA22-7000-0_370_**
> Principles_Of_Operation_Jun70.**pdf
>
>