Re: Specifying

----- Original Message -----
> I have uploaded a draft of the High Resolution Time spec here:
> Please review the spec and provide feedback.
> I have also updated Resource Timing, User Timing and Performance
> Timeline to use the DOMHighResTimeStamp defined in the High
> Resolution Time. Please review the timing spec changes as well.

[Adding Luke Wagner, who is working on this with me on the Mozilla end.] 

Thanks. The draft looks good to me. I especially like the list of example applications. Our biggest general question is, "Does this fit well with what we can easily implement?" I.e., can Windows Performance Counters/gettimeofday do the job with minimal assistance? Based on a bit of digging today, it looks easy enough for implementers. 

Detailed comments/questions below. Mostly just commentary and implementation notes--the most substantive question is about whether we need time zero to be start of navigation.

[4.2] "A DOMHighResTimeStamp represents a number of milliseconds"

Was milliseconds chosen for compatibility with other timing APIs? Seconds seems nicer conceptually but I understand if all the other related APIs are already ms.

[4.2] "represents a number of milliseconds accurate to at least a tenth of a millisecond."

I'm curious about the rationale for this requirement. The users I talked to seemed to just want the best precision possible on the given system, so they wouldn't need such a requirement. But I don't see a problem with having the requirement.

[4.3] "On getting, the now attribute MUST return the number of milliseconds from the start of the navigation of the root document to the occurrence of the call to the now attribute."

The main application of seems to be relative timing, which doesn't particularly require any origin. It seems to me to be a bit easier to allow an arbitrary origin, so that the implementation doesn't have to track a zero time and subtract. Do some important applications require zero to be start of navigation?

[4.4] "MUST be monotonically increasing and not subject to system clock adjustments or system clock skew"

Just to make sure I understand, does "not subject to system clock adjustments" mean that two calls to must measure the true wall clock interval even if the system clock was reset by the user in between?

This seems to be a good requirement in principle but I'm not deeply knowledgeable about how easy it is to implement on different platforms. 

IIUC, on Unix, gettimeofday() will not meet this requirement--it returns the current time since the epoch, so it depends on the system clock. But |clock_gettime(CLOCK_MONOTONIC, &t)| presumably does the right thing. On Windows, |QueryPerformanceCounter| seems to try to be monotonic, but the docs say it could fail if there are bugs in Windows HAL or the BIOS:

    On a multiprocessor computer, it should not matter which 
    processor is called. However, you can get different results 
    on different processors due to bugs in the basic input/output
    system (BIOS) or the hardware abstraction layer (HAL).

I assume hardware bugs are mostly out of the scope of spec compliance, so that probably doesn't matter. 

Given the above, it seems the monotonicity requirement should be implementable on Posix and Windows.

[4.5] "it does not make this privacy concern significantly worse than it was already."

That's also what I've been told. :-) The argument was that timing attacks work fine with low-resolution timers, they just take longer, so having only low-resolution timers just gives a false sense of security. That makes sense to me.


Received on Wednesday, 29 February 2012 08:25:59 UTC