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

[Scott Burleigh]

Keith Scott wrote:
> 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.)

Sure, you clearly won't have any greater precision in time expression than you get from the number of bits you're using to express time units of various sizes (hours, minutes, seconds, microseconds or nanoseconds or quarter-billionths of a second).

But you may not really be (in fact, in most cases are not) getting that precision either.  If you're sampling time from a clock that ticks only 60 times per second, then even though your seconds fraction is expressed as a 32-bit number with values ranging from 0 to (2**32 - 1) you can't believe most of those bits: the only possible values the fraction can take on are integral multiples of (2**32)/60, which is the real precision at which you are reporting the time, and you can't infer this precision just by looking at the time representation and seeing a 32-bit fraction.

> 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

I think so; that's what I meant by reporting the error in plus/minus clock ticks.

 (which themselves are
> API-dependent).

Again, I don't think the API really matters here; I think what matters is the granularity of operation of the time source ("clock", whether a local electronic clock or the operation of NTP, or whatever) itself.

  Something like: "the accuracy indication is in the same
> units as the time indication,

Yes.

 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 think that's right, though reporting a meaningful probability seem difficult to me.

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

Absolutely.

  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.

Sure; in that case the TDS itself is functioning as the local clock, and none of those other three clocks is considered the authoritative ("reference") time source for the purpose of reporting accuracy; some other clock somewhere, that you wish you could sync with all the time but usually can't, is the reference time source.

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

I really think these are different things that need to be reported in different parameters of the indication; but you're right, let's hear what NTP does.

Scott