[96144] in North American Network Operators' Group
Re: BGP Problem on 04/16/2007
daemon@ATHENA.MIT.EDU (Douglas Otis)
Thu Apr 19 14:22:10 2007
In-Reply-To: <86vefs5mab.fsf@seastrom.com>
Cc: "David Temkin" <dave@rightmedia.com>, <nanog@merit.edu>
From: Douglas Otis <dotis@mail-abuse.org>
Date: Thu, 19 Apr 2007 11:21:20 -0700
To: "Robert E. Seastrom" <rs@seastrom.com>
Errors-To: owner-nanog@merit.edu
On Apr 19, 2007, at 10:03 AM, Robert E. Seastrom wrote:
>
>
> "David Temkin" <dave@rightmedia.com> writes:
>
>>> From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On
>>> Behalf Of Warren Kumari
>>> Yup, Sandia National Labs made a radiation hardened Pentium and,
>>> as far as I remember, was working on a hardened SPARC -- there
>>> was also some work done (AFAIR on PPC) whereby 3 processors would
>>> run the same instructions and vote on the output...
>>
>>
>> Thinking of perhaps Resilience? http://www.resilience.com/
>>
>> God, those things were horrid before they realized that the
>> business model of assuming "The app will always be OK, the issue
>> will be the hardware" was completely misguided. I forget what the
>> product was named at the time, but I'll never forget what a piece
>> of crap it was.
>
> Eh, they're not the only folks to have had voting-muti-cpu-lockstep-
> execution hardware platforms. Stratus did it for years; the Tandem
> Integrity S2 (to which I ported Emacs 18.55 many moons ago) was
> similar.
I helped develop a digital communication system for the Navy at Huges
back in the early 80s. We could only use fusable ROMS and rad-hard
8080s. (No break points.) Crystals where nudged into lock for three-
way synchronous voting on defective systems/hardware. Mechanical
inputs were also redundant, and of course a bear to resync. This
lead to a snafu during war games with an aircraft carrier, where the
air controller panel's gray-code rotor switches were erroneously
flagged as defective during peak use. Luckily everyone lived.
-Doug
