Comment on High Resolution Time Last Call Draft

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

Received on Tuesday, 13 March 2012 17:17:46 UTC