Re: Duration vs. Ada.Real_Time

[Marin David Condic <mcondic.auntie.spam@acm.org>]

Actually, the problem was a lot more specialized than what you seem to be
gathering from my post. Basically, it was two separate, identical computers
running identical software with independent 1.024mS interrupts. (No common
time source or this would have been a source for common-mode failure)

Given the presence of watchdog timers in both boxes that had to be stroked
on specific cycles and the need for each computer to be operating on
identical sensor input, you wanted to have them sync'ed on the same cycle
and starting each cycle with a high degree of precision. (I believe we
settled on about 50uS as a jitter amount, so that was roughly the tolerance
of the sync.)

We had primitive communications between the two CPU's - a Manchester data
link and a couple of discretes.

We achieved sync by basically having the two machines look for each other on
the discretes and one machine taking small delays until they both arrived at
the same cycle. From there, we pulled a few other tricks involving delays
until the machines were in fine sync. (BTW, the same basic problem happens
with frequency-hopping radios where you don't have a common time source or
you can't get the time source until you achieve coarse sync.)

Basically, we came up with a solution that worked, but I could never get
over the feeling that some academic type had probably written a book or a
paper discussing various methods of doing this which might have shed some
light on better ideas.

Network time synchronization is far more heavily studied, but doesn't have
quite the same set of problems.

MDC

Buz Cory wrote:

> On 1/29/01, 1:40:29 PM, Marin David Condic <mcondic.auntie.spam@acm.org>
> wrote regarding Re: Duration vs. Ada.Real_Time:
>
> [snip]
>
> > BTW: I've asked before when I was dealing with that same situation
> > - two machines that want to operate in lockstep.
>
> You failed to say to what degree of precision. Am assuming below that
> a discrepancy on the order of 10ms is OK.
>
> > Do you know of any sort of formal, published writings on
> > algorithms to do this? We had a 1.024mSec interrupt on both sides
> > - no clock so no "delay until"
>
> You mean you had a periodic interrupt and weren't counting?
>
> If you were counting, then there was your clock. It may have had to
> be set externally to sync w/ external time, but it was still there.
>
> One would assume that the 1.024 ms interrupt came from a HW device
> counting 1MHz pulses. If that register was readable somehow, now you
> had a time resolution of 1�s.
>
> Naturally, if the 1MHz signals are separately generated for each
> box, there will be some drift (though I wouldn't expect a lot). One
> way to solve this would be to provide the base tick externally.
>
> > - and some hardware signaling between the two. We came up
> > with ways of doing the sync, but I kept thinking in the back of my
> > mind that better/faster/easier ways of doing it. Not horribly
> > important now since I'm not dealing with that same problem, but it
> > has always bothered me enough to still want to read some
> > books/papers on the subject.
>
> Assuming that since the boxen had to be in lock-step, they were
> networked in some way, there is definitely a software solution
>
> Assuming an ethernet LAN, synching w/ an error < 10ms is claimed by
> the author. (Maybe an order of magnitude worse for a WAN.)
>
> The docs that came w/ xntpd may be read at:
>     "http://BuzCo.PenguinPowered.com/imports/net/time/".
> Unfortunately, the PenguinPowered.com nameserver is down as I write
> this :-< (Between ISP problems and nameserver problems I seem to get
> some 80% availability).
>
> You can find basic material on this at "http://www.ntp.org/".
> The software may be downloaded (documented in *_great_* detail) from
>     "ftp://ftp.udel.edu/pub/ntp/".
>
> The algorithms, the software, and the related RFCs (referenced in
> the docs) are all the work of one Dr. David Mills, who seems to be
> The Expert on network time synchronization. I know I could not
> follow the details, I just use the software.
>
> BTW, using the supplied software assumes that you are running some
> variant of Un*x; the provided daemon runs in user-space but can talk
> to the kernel software that maintains time-of-day.
>
> The code is in "C" and gives some warning messages when compiled w/
> gcc.
>
> Hope this helps,
> == Buz :)
> --
> Buz Cory of Buzco Systems -- New York NY USA
> http://BuzCo.PenguinPowered.com
> <netadm@BuzCo.PenguinPowered.com> (Buz as Net Admin)
> write to <helpdesk@BuzCo.PenguinPowered.com> for FREE help with:
>     Installing/Configuring Linux
>     Getting started with the Ada Programming Language.
> Replacing DOS/MS-Win with Linux is like replacing a Fokker with an
> F14.
> Programmer? Bugs got you down? Ada is the answer.

--
======================================================================
Marin David Condic - Quadrus Corporation - http://www.quadruscorp.com/
Send Replies To: m c o n d i c @ q u a d r u s c o r p . c o m
Visit my web site at:  http://www.mcondic.com/

    "I'd trade it all for just a little more"
        --  Charles Montgomery Burns, [4F10]
======================================================================