W3C home > Mailing lists > Public > public-webtiming@w3.org > June 2015

Re: Monotonic clock?

From: Ingar Mæhlum Arntzen <ingar.arntzen@gmail.com>
Date: Fri, 12 Jun 2015 13:40:06 +0200
Message-ID: <CAOFBLLrbYaPtKPPBWeb2faKfkxyCoupCBZvnrCrrScqT=q2PeQ@mail.gmail.com>
To: Francois Daoust <fd@w3.org>
Cc: public-webtiming@w3.org
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

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.


2015-06-12 12:20 GMT+02:00 Francois Daoust <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, 12 June 2015 11:40:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:25:14 UTC