[Sois-tcoa] Time Distribution - again

[Scott Burleigh]

Keith Scott wrote:
> Abhijit,
> 
> All good points.  Some of these will depend on whether or not we think of
> the time distribution service as something that's 'always there' (in which
> case the service will have maintained and 'ready-to-go' a notion of the
> current time that it will use when responding to requests), or whether it
> will be a more 'on-demand' kind of service as I had originally posted.
> Maybe we could come to consensus on just that question first, regardless of
> formats or getting into the details?

I think this may be the crux of the matter.  Going back to Chris's November 29 email, I completely agree with his point that "we must
also bear in mind that this kind of service is often provided in hardware.  Therefore, we must be careful that we do not preclude the use of different mechanisms to provide the service."

To my mind, this means that the time service supported by TCOAS should comprise just a single Time.request that simply returns the current time -- to the best of the service's knowledge, and maybe with an indication of time tick granularity and/or error margin -- regardless of how that knowledge is acquired.  Maybe NTP is running in the background, synchronizing with an NTP server somewhere; maybe some other TBD time synchronization service is running in the background instead, leveraging off the peculiar characteristics of this spacecraft; maybe the TCOAS service implementation has access to an atomic clock that is so accurate that synchronization with more authoritative clocks is unnecessary.  To the user of the TCOAS timer service, this shouldn't matter; therefore it shouldn't matter to the abstract service interface.

We have an opportunity to keep this very simple.  I think we should seize that opportunity and leave the complexity to future implementations.

Scott

> As for the mechanisms, I think that your notions are all good, and that once
> we settle on exactly what it is we're providing, we can tackle the how.
> 
> 		--keith
> 
> 
>>-----Original Message-----
>>From: sois-tcoa-bounces at mailman.ccsds.org 
>>[mailto:sois-tcoa-bounces at mailman.ccsds.org] On Behalf Of 
>>Abhijit Sengupta
>>Sent: Thursday, March 03, 2005 5:34 PM
>>To: sois-tcoa at mailman.ccsds.org
>>Subject: [Sois-tcoa] Time Distribution - again
>>
>>Continuing on time distribution services, here are some 
>>thoughts on other 
>>services, parameters, implementation etc etc
>>
>>   * The time value might be used as the internationally 
>>accepted standard 
>>as year-month-date-T-time etc - for example 20050310T145959.45 
>>means 550 
>>msec before 3pm of 10th March of 2005 at GMT.
>>   * Some implementation aspect: I presume the following:
>>       * when a user application A1 running on processor Pi invokes 
>>Time.Request on processor Pj, TDS running on Pi checks whether i = j,
>>                         i.      if true, Pi issues 
>>OS-dependent "time" 
>>command or accesses "time counter" in hardware to determine 
>>the current 
>>time and responds to A1 (through Time.indication)
>>                        ii.      if false, sends an "inquiry" 
>>message to 
>>TDS on Pj using MTS or some form of AMS (basically using some 
>>messaging 
>>service) and responds with received data (through Time.indication)
>>   * when TDS running on processor Pi receives an "inquiry" 
>>message from 
>>the messaging system,
>>                         i.      Pi extracts request token, 
>>sender id from 
>>message
>>                        ii.      Pi issues OS-dependent 
>>"time" command or 
>>accesses "time counter" in hardware to determine the current time
>>   * If using the messaging system, the timeout is used to 
>>define latency 
>>bound in QoS.
>>   * If lower layer returns QoS cannot be satisfied, 
>>Time.indication is 
>>issued with error condition - basically I am assuming if the 
>>timeout cannot 
>>be satisfied, then the inquiry does not go out.
>>   * A more realistic alternative to 3(d):
>>       * presuming timeout interval is not "critical" and it 
>>identifies 
>>after what interval the time value will be known, instead of 
>>timeout an 
>>interval driven mechanism
>>   * Data structure:
>>       * The messaging system on requesting side puts a time 
>>stamp of its 
>>own clock on the message and also the messaging system on 
>>recipient side 
>>puts a time stamp of its own clock when message is received.
>>       * Similar time stamp while sending responses
>>       * These provide some estimate of propagation delay and delay 
>>because of processing overhead on each side. Such estimate 
>>might be useful 
>>for time critical cases.