- From: Noah Mendelsohn <nrm@arcanedomain.com>
- Date: Tue, 13 Mar 2012 13:17:08 -0400
- To: public-web-perf@w3.org
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