Re: Monotonic clock?

Hi,

It took some time to process, but just to ensure I get this right, 
requiring a Timing Object to use a monotonic clock in a distributed 
context would mean that the "timestamp" property of such a timing object 
does not necessarily follow the system clock anymore, right?

For instance, let's say I call query() at system clock TS1 and get a 
vector whose timestamp is TV1 in return.

Now, if I call query() at system clock TS2 = TS1 + 1.0, I will get a 
vector whose timestamp TV2 may be (slightly) different from TV1 + 1.0, 
depending on skew adjustments that may have been running in the 
background and in the meantime. The only insurance that I have is that 
TV2 will be greater than TV1.

A side consequence is that, as opposed to what I have in my prototype 
code right now (monotonicity is not a guarantee), the skew estimation 
that runs in the background will thus affect the speed of the local 
clock used to compute the timestamp property of a timing object but will 
not result in a "change" event being triggered on the timing object.

Is that correct?

Francois.

On 2015-06-12 13:40, Ingar Mæhlum Arntzen wrote:
> Hi Francois.
>
> A monotonic clock is absolutely a reasonable requirement. In the single
> device setting performance.now() gives this guarantee I believe, and
> also protects against disturbing adjustments to the system clock.
>
> The distributed context implementations of clock sync should ideally
> provide this guarantee as well.
>
> This guarantee is very important in a number of systems whose
> correctness depend exact time ordering and such.
>
> In practice though, in the Web these are likely small effects compared
> to the imprecision of timeouts and media players and such, and error are
> either not so consequential or even hard to detect, so I'm not sure if a
> failure to provide this guarantee is something that anyone would really
> notice?
>
> Anyway, I don't see any reason why we should not mandate this in the
> spec. It should not be a huge cost, and a few years down the road it
> could even prove important.
>
> Ingar
>
>
>
>
>
> 2015-06-12 12:20 GMT+02:00 Francois Daoust <fd@w3.org <mailto:fd@w3.org>>:
>
>     Hi all,
>
>     Both Media elements and Web animations seem to rely on monotonically
>     increasing positions [1] [2], in other words, a clock that is always
>     increasing. I wonder whether we should mandate something similar in
>     the Timing Object specification, more precisely for the "local
>     timestamp" computed for the state vector.
>
>     In the online case, the "local timestamp" is computed from the
>     timestamp received from the server based on an estimation of the
>     local clock's skew against that of the server. When that estimation
>     changes, the conversion can return a local timestamp that lies in
>     the past of the last one, thus breaking the monotonicity.
>
>     Forcing the local timestamp to be monotonic would entail that the
>     position of the timing object is also monotonic in the absence of
>     state vector updates.
>
>     In turn, this could perhaps help integrating the timing object with
>     Web Animations and Media Elements.
>
>     Note that there are different ways to create a monotonic (I think
>     the Media State Vector paper references a couple) and I'm not
>     suggesting to mandate a particular mechanism.
>
>     Is it needed, useful, too early to tell? I confess I do not know
>     whether using a monotonic clock is a must in most cases, a
>     nice-to-have or something that is only ever required in specific
>     cases, so apologies if the idea is essentially dumb...
>
>     Francois.
>
>     [1] http://w3c.github.io/web-animations/#global-clock
>     [2]
>     http://www.w3.org/html/wg/drafts/html/master/semantics.html#playing-the-media-resource
>
>

Received on Friday, 3 July 2015 14:00:33 UTC