[Sois-tcoa] RE: Time Distribution
Keith Scott
kscott at mitre.org
Thu Mar 3 17:05:46 EST 2005
I believe that the actual time format would be the subject of an actual
protocol specification (like if we were to spec a time distrubiton service,
rather than just a service interface). Given Chris's comments in his (much)
earlier email, I'm not sure if we're on the hook for that or not.
Regardless, we'll need a service interface, so it sounded like a good place
to start. It's also easier (I think...).
In conversations with Scott, he expressed the opinion that the time
distribution service should always return an answer immediately. This would
remove the 'timeout', and possibly the 'accurary' parameters from the
time.request primitive. Calls to time.request would simply return the
current time and a notion of its accuracy. This would make sense, though it
would probably require the time distribution service to be 'running' all the
time.
In thinking about the service primitives, I think we can break what we (or
at least I) have been thinking of when I think of time distribution into
separate pieces:
1) Distribute a 'common view' of the current time
2) Synchronize all local clocks to match that view
JUST as an example, there's a lot of stuff in NTP that is concerned with
(1). There's a lot of the machinery to acquire the 'current' time from
different sources (other machines, GPS, RF, other electro-mechanical
gadgets), measure network RTTs (if applicable), filter the measurements,
deal with multiple peers/parents, .... The result of all of this is: a
notion of what the 'current time' is, kept somewhere in the bowels of the
ntp daemon. NTP _also_ has machinery to support (2). There's nothing that
says that one has to use the result of the time distriubution service to
mess with the local clock setting; were we to actually implement the TDS, we
could simply provide an API to allow applications to get the current time.
One might even envision a 'what format I want the time in' parameter in the
API, though I think that such a thing might just be taken care of naturally
in an API (getTimeAsSecondsSinceMyBirthday()). The service interface would
remain the same, regardless of the format. This is sort of important, since
if you've already got a generic time distribution service, it might well be
better-suited to be the actual service than NTP.
Speaking of which (even though it's waayyyy outside the scope of the service
interface discussion), any chance you could point this group at a document
describing the time distribution service you've got?
--keith
>-----Original Message-----
>From: Jane K. Marquart [mailto:Jane.K.Marquart at nasa.gov]
>Sent: Tuesday, March 01, 2005 12:48 PM
>To: Keith Scott; sois-tcoa at mailman.ccsds.org
>Cc: philippe.david at esa.int; Rick.Schnurr at nasa.gov;
>patrick.plancke at esa.int; Massimiliano.Ciccone at esa.int;
>Ashton.G.Vaughs at jpl.nasa.gov; tyamada at pub.isas.ac.jp; 'Amalaye
>Oyake'; SCOTT.C.BURLEIGH at jpl.nasa.gov
>Subject: Re: Time Distribution
>
>Hi Keith,
>
>Please bear with me while I ask what may be dumb
>questions..... In the
>"primitive" world, how does one derive the format of the time,
>i.e. UTC,
>TAI, etc? Is this outside the scope of a primitive? (Sorry
>Chris, some
>of us can only handle abstractions to a certain degree :<)
>The reason I
>ask is that we developed a generic time service that we use
>with our core
>software. Although the format is not a parameter in the API,
>it was still
>necessary to have it defined somewhere so that each
>application didn't have
>to do the conversions. So in the abstract world, it would
>seem to me that
>format has the same kind of place as accuracy.
>
>Enlightenment on the subject is appreciated!
>Jane
>
>
>At 06:08 PM 2/28/2005 -0500, Keith Scott wrote:
>>And on the subject of time distribution...
>>
>>I've attached the last message exchange on the subject of
>time distribution.
>>Going back over Chris's message, I think we should be able to
>knock out the
>>abstract service interface for time distribution right quick.
> To that end I
>>propose the following service specification. What other
>perameters do we
>>need? Are there other services?
>>
>>Although I dearly love abstract service specifications, I
>sort of like to
>>know they're realistic, so maybe we could come up with a
>couple example use
>>cases to see if this thing fits the bill, and to think about
>how one MIGHT
>>implement it (sort of an existance proof).
>>
>>I didn't ask for meeting space in Athens to talk about this,
>let's see how
>>much progress we can make over email?
>>
>> --keith
>>
>>==== Draft TD service specification ====
>>
>>Definitions:
>>
>>Request Token: A handle passed from users of the time
>distribution service
>>when requesting the current time. The token is returned in the time
>>response. By supplying different tokens with different
>requests, a user can
>>associate responses with corresponding requests.
>>
>>Accuracy Specification: An indication of the accuracy of a
>particular time
>>value (need to specify semantics here (units, at least) -- I
>suspect the
>>right verbiage exists if I can just find it.) Will need to be able to
>>specify "no answer" (infinite variability) in case things fail.
>>
>>Time Source Identifier: An indication of which TD time
>service 'master' the
>>user would like to use. (In practice, a default value should
>yield 'any').
>>
>>Timeout: A value indicating the maximum amount of time before
>an answer must
>>be returned.
>>
>>TIME.REQUEST
>>
>>The Time.request primitive shall be used by a user of the
>time distribution
>>service to request the current time.
>>
>>Semantics: Time.request shall provide parameters as follows:
>> Time.request ( request token,
>> accuracy specification,
>> time source identifier,
>> timeout)
>>
>>When Generated: GetTime.request is generated by users of the time
>>distribution service when they want to request the current time.
>>
>>Effect on receipt: Receipt of a Time.request shall cause the
>TD service to
>>determine the current time, to the specified accuracy, using
>the specified
>>time source. If an answer cannot be provided by the timeout,
>the TD service
>>may return an answer with lower accuracy.
>>
>>
>>
>>TIME.INDICATION
>>
>>The Time.indication primitive shall be used to deliver the
>current time,
>>with specified accuracy and precision, to a user of the TD service.
>>
>>Semantics: Time.indication shall provide parameters as follows:
>> Time.indication( request token,
>> accuracy specification,
>> time)
>>
>>When Generated: Time.indication shall be generated in response to a
>>Time.request request.
>>
>>Effect on receipt: The effect on receipt of a Time.indication
>by a TD user
>>is undefined.
>>
>>Additional comments: The accuracy specification provided with a
>>Time.indication gives the accuracy of the accompanying time
>value. We need
>>to specify some semantics here (units, at least).
>>
>>============================
>>
>> > -----Original Message-----
>> > From: Abhijit Sengupta [mailto:Abhijit.Sengupta at jpl.nasa.gov]
>> > Sent: Monday, February 28, 2005 2:33 PM
>> > To: Stuart.Fowell at scisys.co.uk
>> > Cc: c.plummer at skynet.be; Massimiliano.Ciccone at esa.int;
>> > Patrick.Plancke at esa.int; kscott at mitre.org
>> > Subject: Re: Draft TCOAS Web Page
>> >
>> >
>> > Some more comments - I put them in brown font in comment box.
>> > (Strangely enough my previous comments got their date and
>> > time changed and accordingly my previous comments have later
>> > time stamp than the later comments - I guess artifacts of
>> > Microsoft brilliance).
>> >
>> > I am sending copy to Keith also for his comments on TDS.
>> >
>> > Abhijit
>> >
>> > At 2/28/2005 03:58 AM, Stuart.Fowell at scisys.co.uk wrote:
>> >
>> >
>>
>>From: "Chris Plummer" <c.plummer at skynet.be>
>>Sender: <sois-tcoa-bounces at mailman.ccsds.org>
>>To: "'Keith Scott'" <kscott at mitre.org>,
>> "'Scott Burleigh'" <Scott.Burleigh at jpl.nasa.gov>,
>> <Stuart.Fowell at scisys.co.uk>
>>Cc: "'Abhijit Sengupta'" <Abhijit.Sengupta at jpl.nasa.gov>,
>> "'Stuart Fowell'" <Stuart.Fowell at scisys.co.uk>,
>> <philippe.david at esa.int>,
>> <sois-tcoa at mailman.ccsds.org>,
>> <Rick.Schnurr at nasa.gov>,
>> <patrick.plancke at esa.int>,
>> <Jane.K.Marquart at nasa.gov>,
>> <Massimiliano.Ciccone at esa.int>,
>> <Ashton.G.Vaughs at jpl.nasa.gov>,
>> <tyamada at pub.isas.ac.jp>,
>> "'Amalaye Oyake'" <amalaye.oyake at jpl.nasa.gov>,
>> <SCOTT.C.BURLEIGH at jpl.nasa.gov>
>>Subject: [Sois-tcoa] RE: SOIS Time Distribution Service
>>Date: Mon, 29 Nov 2004 18:27:57 -0500
>>Message-ID: <200411292327.iATNRwoF007078 at outmx021.isp.belgacom.be>
>>MIME-Version: 1.0
>>Content-Type: multipart/alternative;
>> boundary="----=_NextPart_000_00CE_01C51DC0.7DFAEC50"
>>X-Mailer: Microsoft Office Outlook, Build 11.0.5510
>>X-MITRE-External: True
>>X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data:
>>2004.11.30.2
>>In-reply-to: <200411292017.iATKH4N01256 at smtp-bedford-dr.mitre.org>
>>X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
>>X-BeenThere: sois-tcoa at mailman.ccsds.org
>>X-Mailman-Version: 2.1.4
>>List-Subscribe:
>><http://mailman.ccsds.org/mailman/listinfo/sois-tcoa>,<mailto:
>sois-tcoa-request at mailman.ccsds.org?subject=subscribe>
>>List-Unsubscribe:
>><http://mailman.ccsds.org/mailman/listinfo/sois-tcoa>,<mailto:
>sois-tcoa-request at mailman.ccsds.org?subject=unsubscribe>
>>List-Help: <mailto:sois-tcoa-request at mailman.ccsds.org?subject=help>
>>Thread-index: AcTWSEXI5dP48ShWTVy5fDocoHk2PAAA6z8gAAcPvDA=
>>X-Mailman-Approved-At: Tue, 30 Nov 2004 17:38:44 -0500
>>
>>Hi Keith,
>>
>>It gets my vote with a couple of provisos:
>>
>>Firstly, let's keep well away from the dreaded "API"
>terminology. We are all
>>grown ups here and can handle abstraction! (-Oh boy....am I
>going to regret
>>saying that). Instead let's stick with an abstract service interface
>>definition in true ISO 7498 style.
>>
>>Secondly, I'm sure that an NTP-like protocol is the right way
>to go and that
>>we should concentrate our initial efforts in this direction,
>but 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.
>>
>>I fully agree that a high accuracy time service is not part
>of the charter.
>>There will always be cases where one payload or system onboard the
>>spacecraft needs a high accuracy time service, but these are
>the minority.
>>Most applications will want a modest accuracy, wall-clock
>type time service,
>>and these are the applications we, SOIS, should cater for.
>>
>>Finally, sincere apologies on the part of Patrick and myself
>that no-one
>>showed up for the time distribution session. We had had to dynamically
>>re-shuffle the agenda to cater for some of the joint meetings
>and could not
>>get word of this to you. We will endeavour to do better next time!
>>
>>Cheers,
>> Chris.
>>
>>-----Original Message-----
>>From: Keith Scott [<mailto:kscott at mitre.org>mailto:kscott at mitre.org]
>>Sent: 29 November 2004 21:17
>>To: 'Scott Burleigh'; Stuart.Fowell at scisys.co.uk
>>Cc: 'Amalaye Oyake'; philippe.david at esa.int; patrick.plancke at esa.int;
>>Massimiliano.Ciccone at esa.int; 'Stuart Fowell'; c.plummer at skynet.be;
>>tyamada at pub.isas.ac.jp; Jane.K.Marquart at nasa.gov;
>Rick.Schnurr at nasa.gov;
>>'Abhijit Sengupta'; SCOTT.C.BURLEIGH at jpl.nasa.gov;
>>Ashton.G.Vaughs at jpl.nasa.gov; sois-tcoa at mailman.ccsds.org
>>Subject: RE: SOIS Time Distribution Service
>>
>>Stuart,
>>
>>I was supposed to lead a time distribution group meeting on
>Tuesday when I
>>got into Toulouse, but nobody else showed up. Attached are
>the slides I was
>>going to present to see if there was consensus to 're-synch' time
>>distribution around (my interpretation of) what's in the TCOA charter.
>>Namely, I think time distribution should provide a mechanism (API) for
>>_applications_ running on different _nodes_ of a spacecraft to get the
>>current time. I think that distributing the 'current time'
>between nodes of
>>the spacecraft is in scope, and think that an NTP-like
>protocol could work
>>for this. The important things here are that there are applications,
>>presumably running on some sort of operating systems and
>general-purpose
>>hardware (nodes).
>>
>>I think previous discussions of time distribution got
>off-track (partly my
>>fault, since I hadn't gone through the TCOA charter carefully until
>>preparing for Toulouse). In particular, I do NOT think that the time
>>distribution mechanisms we propose have to handle the extremely
>>high-fidelity/low overhead cases that Art was concerned
>about. Instead I
>>think that if there are instruments that want to just count
>rising edges off
>>a common clock, great. Those instruments can do whatever
>they'd normally do
>>-- put copies of the counter in their data stream.
>>
>>If you want to 'synch' that square wave clock to 'the current
>spacecraft
>>time' as defined by the time distribution service, I'd simply
>have some node
>>with access to the square wave snap a copy of the counter and
>timestamp it
>>with the time distribution service (TDS) time. This leaves
>some ambiguity
>>between the 'square wave time' and the 'TDS' time (since the
>TDS resolution
>>will likely not be one cycle of the square wave the counter
>is watching),
>>but it also decouples the two services. It would be very
>difficult for a
>>reasonable time distribution service to cover all of Art's
>requirements.
>>
>>So, how do people feel about backing off to this
>interpretation of what's in
>>the TCOA charter? I'm hoping we can handle a lot of this
>type of discussion
>>over email, and it would be nice to get this activity moving in some
>>direction; now's the time to speak up!
>>
>> --keith
>>
>> >-----Original Message-----
>> >From: Scott Burleigh
>>
>[<mailto:Scott.Burleigh at jpl.nasa.gov>mailto:Scott.Burleigh at jpl.
>nasa.gov]
>> >Sent: Monday, November 29, 2004 2:18 PM
>> >To: Stuart.Fowell at scisys.co.uk
>> >Cc: kscott at mitre.org
>> >Subject: Re: SOIS Time Distribution Service
>> >
>> >At 03:26 AM 11/26/2004, you wrote:
>> >>Hi Scott,
>> >>
>> >>Hope you had an easy journey back to your side of the pond.
>> >>
>> >>I wonder if you could help me. I'm putting together a
>proposal for the
>> >>on-board software for a European reference mission and in
>> >particular the
>> >>communication services.
>> >>Of course I'm making extensive reference to the current
>> >state-of-the-art
>> >>with regard to SOIS.
>> >>
>> >>I have a reasonable handle on TCONS, MTS, File Transfer, C&DA
>> >etc but not
>> >>on the Time Distribution Service. I have the presentations
>> >Art gave at the
>> >>Montreal meeting but I've no information on any progress
>> >made/what happened
>> >>in Toulouse. If you have any info, presentations, reports or
>> >commentary I
>> >>would really appreciate it. The proposal has to be submitted
>> >3rd December
>> >>so if you have anything I really could do with it by 30th Nov.
>> >
>> >Hi, Stuart. I don't know what happened in the Time
>> >Distribution Service
>> >area at Toulouse, but if anyone does know I think it would be
>> >Keith Scott;
>> >I'm copying him on this reply. Keith, any information you can
>> >pass on to
>> >Stuart?
>> >
>> >Scott
>> >
>> >
>>
>>_______________________________________________
>>Sois-tcoa mailing list
>>Sois-tcoa at mailman.ccsds.org
>><http://mailman.ccsds.org/mailman/listinfo/sois-tcoa>http://ma
>ilman.ccsds.org/mailman/listinfo/sois-tcoa
>>
>
>
>
More information about the Sois-tcoa
mailing list