Timing API issues with wall-clock time

Dear web perf working group,

I just noticed that the navigation timing API is defined in terms of 
wall-clock epoch times.  Unfortunately, such times on modern computer 
system have an unpleasant property: they are not monotonically 
increasing at the rate time actually passes at.  In particular, NTP 
adjustments, leap seconds, user configuration changes, and so forth can 
cause the epoch time reported by the system to go backwards, go forwards 
to fast or go forwards too slowly.

In terms of the navigation timing API what this means is that some of 
the durations can be negative (or just completely incorrect).  Worse 
yet, there is no reasonable way to tell when the latter has happened.

I think it would be (have been, if people are not willing to switch at 
this point) to define navigation timing in terms of an epoch start time 
for the navigation and then durations (in whatever time units) from the 
navigation start time for the other times.  That would allow 
implementations to directly measure elapsed time from navigation start 
instead of sampling a wall-clock at two points in time and hoping that 
the difference between the reported values actually corresponds to how 
much time has elapsed.

-Boris

Received on Tuesday, 12 April 2011 09:26:58 UTC