Re: [timingobject] Timestamps and reference clocks

Ah, I'm glad to see that my intuitions can be contagious ;)

Reacting on your specific suggestions:

>  t_now from the timing provider needs to be translated. I think the 
easiest solution would be if timingprovider did this translation as 
part of its .now() method.

That matches what I had initially started to specify, but I think 
"easiest" should apply to the timing provider side in the end, not to 
the user agent. What I mean by that:

1. The interface and requirements that timing providers need to follow
 should remain as simple as possible, because we will have less 
control on timing providers: there will be more of them that may not 
be around the table when the spec is standardized, and allowing 
"regular" (non sync experts) Web app developers to act as timing 
providers sounds like a good thing, even though the result may not be 
that good in terms of actual synchronization.
2. The user agent cannot trust the code provided by timing providers 
by definition: it will have to add a layer on top of that code to 
ensure that it can trap (and/or possibly fix) whatever error timing 
provider code may make, typically failures to respect clock 
monotonicity.
3. The internal clock(s) used by the user agent would likely run in 
another thread (and in another runtime) as Njål pointed out, so the 
user agent will need to synchronize these clocks with the timing 
provider one way no matter what, to be able to respond to compute the 
current state vector whenever it needs to without having to run the 
timing provider code.

Does the user agent need to now how a timing provider timeline map to 
the `performance.now()` timeline by the way? I guess the user agent 
could call `now()` when the timing object is first connected to the 
timing provider object and use that initial mapping as reference to 
relate further timestamps of the timing provider to the 
`performance.now()` timeline.


> I'm a bit worried though that having two clock-sync processes (first
 timing provider and then user agent) instead of just one might make 
the end result less precise. The errors from the first should dominate
 errors from the second - but I don't have the competence to say for 
sure if this is completely safe.

Right, I wondered about that as well. I guess we'll have to wait for 
concrete feedback from implementers. I don't have the competence 
either :)


> In the interest of airing all possibilities; it would also be 
possible to avoid clock sync completely in the timing provider, and 
instead have it simply relay request-response messages on behalf of 
the clock sync algorithm running in the user agent. I suppose this 
would limit the design space for timing providers.

Yes, that's an option. It requires agreeing on a particular clock 
synchronization mechanism: those I reviewed seem to be all alike, 
doing the same computation based on the round trip time... and all 
different when you look into details, for instance the backend may 
push additional sync messages on its own, or the client may send a 
batch of requests and discard the ones that take too long. I would 
keep the idea in the back of our minds until we need it.


> How about the timing provider object managing N timing resources 
instead of just one?

I suppose that it would depend on how the user agent would implement 
the feature but it could well maintain only one clock internally 
shared by the different timing objects connected to the same timing 
provider object. Did you have specific worries on that front?

I note that the idea to require the timing provider code to run in a 
separate JavaScript realm (see issue #10) would make it next to 
impossible to reuse the same timing provider object across timing 
objects, unless we have chaining (see issue #13).

-- 
GitHub Notif of comment by tidoust
See 
https://github.com/webtiming/timingobject/issues/16#issuecomment-134549684

Received on Tuesday, 25 August 2015 10:46:26 UTC