[Sois-tcoa] RE: [Time Distribution -- v3] -- I hate it when I do

c.plummer at skynet.be c.plummer at skynet.be
Tue Apr 12 16:30:27 EDT 2005


Hey Keith, I’m levitating because we’re getting into application details, not because you’re talking NTP. I’m sure that when we get terrestrial-like LANs running onboard NTP will be the right way to go. In the meantime us sneaky onboard guys have got neat solutions to do time correlation between onboard clocks that allow us to live with sub-megabit-per-second buses.
 
Anyway, many thanks for this excellent work. We’ll look through it in the TCOAS session tomorrow and I’m confident that we’ll have a specification that we can resolve to vote forward onto the standards track by the end of the week.
 
Cheers,
            Chris.






Sorry, here's the attachment.

        --keith




From: Scott,Keith L. [mailto:kscott at mitre.org] 
Sent: Tuesday, April 12, 2005 3:20 PM
To: 'sois-tcoa at mailman.ccsds.org'
Subject: [Time Distribution -- v3]


Attached is my cut at v3 of a Time Distribution service spec for TCOAS.  I think this version covers Stuart's \"alarm at\" and \"periodic chime\" services, as well as the standard 'wallclock' service.  The version of 'alarm' I have is an absolute time alarm, not a delay timer version.  I figured that an application wanting a delay timer could simply get the current time, add whatever it wanted to it, and submit the result as the argument to the alarm service.  A single indication (with four parameters) covers all cases.

I stayed away from anything that would 'set' the TDS time, figuring that such actions would be more management (which we may want to include in the document, I just don't have 'em yet).  I really want to stay away from anyting that gets into an implementation, as I secretly (in the far, far future) want to use the time-synchronizing (NOT the clock-setting parts) of NTP as the time distribution mechanism.  Chris levetates out of his chair every time I mention this, so I try to do so often  :)

I'm not particularly clueful about getting the ISO naming convention right, but I also figure that's just a global search-and-replace away, so if somebody has an excellent suggestion for the primitive names, I'm all ears.

I included the POSIX (http://www.opengroup.org/austin/papers/posix_faq.html) time.h specification at the end of the document; there was some discussion of possibly adopting POSIX.  I fear that even a struct tm is a bit heavyweight, but again, would welcome discussion on the topic.

Comments welcome.

        --keith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sois-tcoa/attachments/20050412/378df4af/attachment.html


More information about the Sois-tcoa mailing list