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

[Keith Scott]

Scott,

Precision vs. accuracy:

My thought was that the (TBD) API would specify the format in which the time
was returned, which would implicitly specify precision.  There's a mapping
from the time format to the precision, (e.g. NTPv4 timestamp is so many
bits, struct timeval is so many, ...)  Different APIs would, by their very
nature, provide different levels of precision (like if time is returned in
seconds with no fractional part, well, there you go.)

The accuracy parameter would be exactly as you described.  I apologize that
I haven't yet done the legwork to even try to figure out exactly how this
measure should be expressed (units or semantics).  My thought was that it
might be dependent on the units of the time response (which themselves are
API-dependent).  Something like: "the accuracy indication is in the same
units as the time indication, and provides a value such that the TDS
believes that there is greater than 95% probability that the current time
lies within (time+-accuracy)."

I'd like, if we can, to allow for the possibility that there may be several
'master' clocks, and that each might be supplying different values to the
TDS.  It's not that the TDS is trying to return the 'right' time as
expressed by any _particular_ clock, but rather the _right_ time, taking all
of the sources into account.  Thus the TDS might be watching three clocks
and returning the average, or some weighted average based on how jittery the
clocks have been and what the sources actually are.

Maybe we need to express both precision and accuracy in the time.indication
value.  I'll look up what NTP does in terms of reporting precision and
accuracy to users; maybe that'll provide enlightenment about how to go.

		--keith

> -----Original Message-----
> From: sois-tcoa-bounces at mailman.ccsds.org 
> [mailto:sois-tcoa-bounces at mailman.ccsds.org] On Behalf Of 
> Scott Burleigh
> Sent: Monday, March 07, 2005 3:15 PM
> To: sois-tcoa at mailman.ccsds.org; sois-tcoa at mailman.ccsds.org
> Subject: Re: [Sois-tcoa] Time Distribution -- Take 2 Service Spec
> 
> 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.
> > 
> > ============================
> 
> _______________________________________________
> Sois-tcoa mailing list
> Sois-tcoa at mailman.ccsds.org
> http://mailman.ccsds.org/mailman/listinfo/sois-tcoa
>