[Sois-tcoa] Time Distribution - again

[Scott,Keith L.]

Right, I don't mean to be saying anything about how to implement the TDS.  Based on Scott's and your comments (and my previous discussions with Scott), the time.request primitive might have only some way for an application to associate a response with a particular request.  The time.response could carry the association, the time, and a 'goodness' indication.  How the service determines these things is, at this point, unspecified.

For the _service_specification_, do we care what the location of the time source is?  Could be GPS, TCO, ...   we can just say that the service returns the current time.  Location and number of time sources could matter a lot to implementations, but I'm not sure it matters to the service spec?

When I get to a real keyboard I'll type up a new full service spec for further discussion - unless somebody else has a burning desire to do so in the meantime?    :)

  --keith
--------------------------
Sent from my BlackBerry Wireless Handheld


-----Original Message-----
From: sois-tcoa-bounces at mailman.ccsds.org <sois-tcoa-bounces at mailman.ccsds.org>
To: 'Scott Burleigh' <Scott.Burleigh at jpl.nasa.gov>; sois-tcoa at mailman.ccsds.org <sois-tcoa at mailman.ccsds.org>
Sent: Fri Mar 04 19:10:23 2005
Subject: RE: [Sois-tcoa] Time Distribution - again

Got to wade in here guys. Scott has summarised my picture of the time
service neatly, and this reflects what I have seen done on several
spacecraft, i.e. a local counter in each "node" that is correlated to the
central reference time maintained somewhere in the spacecraft. The actual
mechanism used to do the correlation is variable (and I believe will
continue to be so) because we can often take advantage of inherent
characteristics in the underlying bus, e.g. if it is continuously modulated,
or if someone has taken the trouble of routing the PPS signal all over the
place. Obviously, as we get more capable and performant onboard network
infrastructure we can start to use NTP like services.

Applications hosted on each node therefore treat the "time service" as a
wall clock. Scotts' Time.request is equivalent to glance at the wall clock,
and I believe that this simple service will already provide applications
with an important service.

However, we should also remember that wall clocks can stop, or they may run
slow or inaccurately if they haven't been checked against the reference time
recently. Therefore, we need to convey some indication of the accuracy that
the time service thinks that it has when it responds to a Time.request. This
is relatively easy to do without adding too much complexity, and greatly
enhances the service actually provided to the user.

Another thing that may be of relevance is the location of the onboard
reference time, because this may determine the mechanisms that we can use to
do the time correlation. In the good old days the reference time was usually
a free running counter maintained in the central data handling computer.
With more and more earth orbiting spacecraft running GPS receivers, the GPS
unit logically provides the reference time. 

Chris.

-----Original Message-----
From: sois-tcoa-bounces at mailman.ccsds.org
[mailto:sois-tcoa-bounces at mailman.ccsds.org] On Behalf Of Scott Burleigh
Sent: 05 March 2005 00:12
To: sois-tcoa at mailman.ccsds.org
Subject: Re: [Sois-tcoa] Time Distribution - again

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.

_______________________________________________
Sois-tcoa mailing list
Sois-tcoa at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/sois-tcoa


_______________________________________________
Sois-tcoa mailing list
Sois-tcoa at mailman.ccsds.org
http://mailman.ccsds.org/mailman/listinfo/sois-tcoa