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=0.6 required=5.0 tests=BAYES_40,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: "Peter Jensen" <pjensen@agleader.com>
Subject: Re: Processor Synchronization
Date: 1999/01/21
Message-ID: <788d1f$odp$1@cave1.courtave.net>#1/1
X-Deja-AN: 435411813
References: <36A509DB.95F62C0B@pwfl.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4
X-Complaints-To: abuse@courtave.net
X-Trace: cave1.courtave.net 916961135 25017 208.141.152.33 (21 Jan 1999
 23:25:35 GMT)
Organization: Court Avenue Networks, Inc.
NNTP-Posting-Date: 21 Jan 1999 23:25:35 GMT
Newsgroups: comp.lang.ada,comp.realtime
Date: 1999-01-21T23:25:35+00:00
List-Id: <comp.lang.ada>

I worked on a couple of double and triple redundant control systems.  The
first design used a processor synchronization scheme similar to the one you
described.  The "heart beat" was obtained from a 10 mb/s communications
port.  (Our goal was to sync within a few msec).  Critical data was
exchanged and compared via this port to determine any failures.  We had a
lot of trouble keeping the synchronization working from release to release
do to changes in the timing of the application software.

The second design abandoned synchronization all together and instead allowed
for a reasonable time delay when comparing critical data.  This was simpler,
but obviously can't be used for every type of redundant system.

There are a lot of other issues beyond the scope of this discussion that
must also be considered.

-Pete