From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,5495dac456fa22ef
X-Google-Attributes: gid103376,public
X-Google-Thread: 115aec,5495dac456fa22ef
X-Google-Attributes: gid115aec,public
From: Ken Keys <klkeys@west.raytheon.com>
Subject: Re: Processor Synchronization
Date: 1999/01/19
Message-ID: <36A51F3A.2207F91@west.raytheon.com>#1/1
X-Deja-AN: 434610385
Content-Transfer-Encoding: 7bit
References: <36A509DB.95F62C0B@pwfl.com>
Content-Type: text/plain; charset=us-ascii
Organization: Raytheon Missile Systems
Mime-Version: 1.0
Newsgroups: comp.lang.ada,comp.realtime
Date: 1999-01-19T00:00:00+00:00
List-Id: <comp.lang.ada>

Marin David Condic wrote:
 
 > The most general description of the problem domain I can come up with
is
 > this: The problem is at power-up, you have to get both processors
 > ticking off at the same "heartbeat" so that they have the same frame
of
 > reference. Generally, you're going to have N cycles (frames, slots,
 > whatever your favorite terminology is) and it is important that both
 > processors be operating on cycle X at the same time. Once running,
the
 > processors have to detect drift in their cycling and correct for this
so
 > that they continue to both start on the same cycle at the same time.
We
 > have done this sort of thing in-house, but I'm looking for a
discussion
 > of a variety of algorithms and some analysis of the strengths &
 > weaknesses of each.

How did you do it when did it in-house? Did you use an RTC or some other
common (hardware) time reference?

KLK