[Sois-tcoa] Time Distribution -- Take 2 Service Spec

[Scott Burleigh]

Keith Scott wrote:
> Here's a revised TDS service spec that removes the extra goo in the
> time.request primitive.
> 
> I was trying to think of how an application might make use of a time source
> identifier that told it which time source provided a particular answer.
> Such a thing might be useful if I thought that a particular time source was
> just whacko and I wanted to ignore it.  To make that work, however, would
> require a 'time source identifier' in the time.request primitive (so I could
> then ask for a 'non-whacko' source).  There's also the question of how to
> resolve multiple time sources into a single answer, and how an application
> would find out what the list of available time sources is.  The operative
> part of this is:
> 
> I'm leaning towards a formulation where resolving differences among
> different time sources should be the job of the time distribution service,
> which would simply return its best estimate of the current time along with a
> 'goodness' indicator.  This would NOT show up in the service spec, except as
> a note (see 'additional comments' under time.indication below).
> 
> Thoughts on this approach?  I'm particularly interested if anybody can come
> up with a use for knowing the specific time source vs. just the 'accuracy
> specification'.

I think this approach is exactly right, Keith.

Other comments in-line below.

Scott

> ====  Draft TD service specification B  ====
> 
> Definitions:
> 
> Request Token: A handle passed from users of the time distribution service
> when requesting the current time.  The token is returned in the time
> response.  By supplying different tokens with different requests, a user can
> associate responses with corresponding requests.
> 
> Accuracy Specification: An indication of the accuracy of a particular time
> value (need to specify semantics here (units, at least) -- I suspect the
> right verbiage exists if I can just find it.)  Will need to be able to
> specify "no answer" (infinite variability) in case things fail.

Maybe not "accuracy" so much as "precision".  I think it should always be possible for the time service to tell the requester what the granularity of the reported current time is -- i.e., the duration of a single clock "tick", maybe in nanoseconds -- which would tell the requester what sort of granularity any time-based operations can (at best) occur on.

"Accuracy" would be the time service's best guess at the maximum difference between the current time it's reporting and the True current time as declared by some more authoritative clock.  You'd have to supply the estimated error (plus/minus, in clock ticks) and also the identity of the authoritative clock you're trying to match; the estimated error might be something computed as a function of the length of time since the most recent synchronization exchange with that clock.  (But you could always default to "no answer" as you say.)  Maybe that would be important for some applications, I dunno.  If so, I think it should be a second parameter; the precision of the clock is independently valuable in any case.

> Time Source Identifier: An indication of which TD time service 'master' the
> user would like to use.  (In practice, a default value should yield 'any').

As discussed above, I'd be inclined to omit this.

> TIME.REQUEST
> 
> The Time.request primitive shall be used by a user of the time distribution
> service to request the current time.
> 
> Semantics: Time.request shall provide parameters as follows:
> 	Time.request ( request token )
> 
> When Generated: GetTime.request is generated by users of the time
> distribution service when they want to request the current time.
> 
> Effect on receipt: Receipt of a Time.request shall cause the TD service to
> determine the current time, and return it to the application

in a Time.indication primitive

.  If an answer
> cannot be provided by a system-specified timeout, the TD service may return
> an answer with extremely extremly low, or even meaningless, accuracy
> specification ("I don't know what time it is")

Sure, if this were a precision spec it could return a time-tick duration of some large number of hours, days, whatever.

> TIME.INDICATION
> 
> The Time.indication primitive shall be used to deliver the current time with
> specified accuracy.
> 
> Semantics: Time.indication shall provide parameters as follows:
> 	Time.indication(	request token,
> 				accuracy specification,
> 				time)
> 
> When Generated: Time.indication shall be generated in response to a
> Time.request request.
> 
> Effect on receipt: The effect on receipt of a Time.indication by a TD user
> is undefined.
> 
> Additional comments: The semantics of the accuracy specification need to be
> such that the TDS can return 'I don't know'.
> 
> If there are multiple time sources configured as inputs to the TDS, it is
> the job of the TDS to resolve their inputs into a single time that is
> returned to the application.  The mechanism for resolving multiple time
> inputs is left to the TDS.
> 
> ============================