[Sois-tcoa] Time Distribution - again

[Jane K. Marquart]

So if I follow this correctly, all that's needed to support the time 
service is a single Time.request and an associated "status".   I fully 
agree with this assessment.

Jane

At 01:10 AM 3/5/2005 +0100, Chris Plummer wrote:
>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