Re: Monotonic clock?

Hi Francois and all.

2015-07-03 16:00 GMT+02:00 Francois Daoust <fd@w3.org>:

> 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?
>
>
That is right. It is also right even if we don't introduce the added
requirement for the clock to be monotonic. In the distributed context the
timing object would in principle be following the system clock of the
timing provider instead of its own system clock. This makes sense when you
want distributed clients to be coordinated in time. However, as this remote
clock must be estimated across a network it will naturally be less precise
than the local clock source.

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.
>

It's correct that clock sync adjustments may push the clock estimates back
or forth a bit from time to time. Implementing a monotonic clock will
mainly make sure changes to the clock are introduced gradually, not
suddenly. I'm not really sure if requiring monotony can have negative
effects on precision. If someone can shed some light on this, please do.

It is not correct that TV2 > TV1 is the only guarantee though. Sync error
may in practise (in a probabilistic sense) be bounded. So, we may still
make probabilistic statements about maximum errors, thus making statements
like TS1 + 1.0 - e < TS2 < TS1 + 1.0 + e



> 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.
>
>
Yes. The "change" event refers to vector change - not minor adjustments to
the underlying clock source.

The fact that the underlying clock is not perfect is in practise not
something we need to worry all that much about. For instance, in the
context of timed video playback - the imperfection of the timing object
will likely be dominated by the imperfection of the playback system.

Also, the timing object is not a tick-based construct, with code running on
every time-unit increment. Instead, application code will generally react
swiftly to updates, and then check the status of the timing object every
now and then to adjust. With this usage pattern, imperfections will be very
hard to notice.

Finally, imperfections of the timing object will apply equally to all
components that base their execution that timing object (indeed any timing
object from the same provider), again making the effects hard to notice.

The only pitfall that I am aware of is if both local and remote clock
sources are used in the same application. For instance, if a really long
timeout is registered with setTimeout, targeting a future value of the
timing object, and then the timing object and the local system clock drift
away from eachother in the mean time, the timeout will eventually be too
early or too late. This issue could be addressed by wrapping setTimeout in
some code that forces readjustments of long timeouts.

Hope this is sensible.

Best,

Ingar



> 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
>>
>>
>>