[Sois-tcoa] Time Distribution - again

[Keith Scott]

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?

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.
>
>
>
>Abhijit
>
>
>________________________________________________
>All personal and professional opinions in this email are my own
>and do not represent, in any way, the opinion or policy of JPL
>________________________________________________
>
>
>_______________________________________________
>Sois-tcoa mailing list
>Sois-tcoa at mailman.ccsds.org
>http://mailman.ccsds.org/mailman/listinfo/sois-tcoa
>