The book "Design Of A Computer: The Control Data 6600" by J. E. Thornton, is now available...
Tom Uban
book by Mr. Thornton, who is the current holder of the rights, a scan
is now available at the following location:
http://www.spies.com/aek/pdf/cdc/DesignOfAComputer_CDC6600.pdf
A copy of the correspondence pertaining to permissions can be found in
the last two pages of the scan.
Please be considerate to the author and do not abuse this gift.
--tnx
--tom
J Ahlstrom
GREAT WORK and GREAT NEWS ! ! ! (pardon the shouting.)
Now all we have to do is get Buchholz's
on Stretch.
JKA
--
The fastest way to succeed is to
double your failure rate."
裕homas J. Watson, Sr.
J Ahlstrom
Please express my great appreciation to Mr Thornon
that he has done this. The book is a classic of form and
substance and required reading for anyone interested
in computer architecture at a deeper level than
bar room bets and news group babble.
John K Ahlstrom
--
Parity is for farmers.
attrib S Cray
Al Kossow
tu...@ubanproductions.com (Tom Uban) wrote:
> After being granted permission to copy, scan, and make available this
> book by Mr. Thornton, who is the current holder of the rights, a scan
> is now available at the following location:
>
> http://www.spies.com/aek/pdf/cdc/DesignOfAComputer_CDC6600.pdf
>
As an addendum to this, if someone has a copy that they would be
willing to let me remove the binding, I would like to obtain
a scan at a higher resolution than what we currently have.
Rupert Pigott
news:3CFD00B1...@cisco.com...
> Parity is for farmers.
> attrib S Cray
[SNIP]
I'd be spinning in my grave is I had that attributed to
me... Even in this modern day & age... Bit flips still
happen and the larger the system the more likely...
Cheers,
Rupert
Eugene Miya
Rupert Pigott <dark.try-eati...@btinternet.com> wrote:
>"J Ahlstrom" <jahl...@cisco.com> wrote in message
>news:3CFD00B1...@cisco.com...
>> Parity is for farmers.
>> attrib S Cray
>
>me... Even in this modern day & age... Bit flips still
>happen and the larger the system the more likely...
I would not worry about it. I doubt S. did.
His about face follow on was
Even farmers buy computers.
And he said that all before the Cray-1.
Still an amazing accomplishment.
Larry__Weiss
Asolutely! (from very recent experiences)...the more complex the
system the more likely, and the more costly. A nightmare to
track down just what subcomponent is corrupting bits
once or twice a week when the hardware can't help you.
Rupert Pigott
news:3cfd1c39$1...@news.ucsc.edu...
> In article <adj5u3$4c6$1...@knossos.btinternet.com>,
> Rupert Pigott <dark.try-eati...@btinternet.com> wrote:
> >"J Ahlstrom" <jahl...@cisco.com> wrote in message
> >news:3CFD00B1...@cisco.com...
> >> Parity is for farmers.
> >> attrib S Cray
> >
> >I'd be spinning in my grave is I had that attributed to
> >me... Even in this modern day & age... Bit flips still
> >happen and the larger the system the more likely...
>
> I would not worry about it. I doubt S. did.
Heh, you've never done the MTBF calcs for a real app
using a 4Mbyte DRAM array in the 1990s have you ? I
should repeat those for a 4Gbyte DDRAM array nowadays
and compare notes... :)
> His about face follow on was
> Even farmers buy computers.
>
> And he said that all before the Cray-1.
>
>
> Still an amazing accomplishment.
Sure, but not much use in production if you can't trust
the thing to deliver correct results repeatably. Well,
I'm being a bit harsh, you could use it for keeping you
warm in winter.
Cheers,
Rupert
Rupert Pigott
news:910FA5569BBE6BFC.BC00F821...@lp.airnews.net...
Actually I can think of scenarios where it really doesn't matter
if you have the odd bit flip... There are algorithms out there
which "heal" if you give them enough cycles, so even if the data
does get knocked out of shape they'll still converge on the result.
I'm guessing that Supercomputer folks would tend to pick
alogorithms with self-healing properties anyway, simply because
they make the result less prone to rounding errors.
Even if you're using such an algorithm, I still think that it
would be prudent to have an ECC protected region for instruction
and critical data storage for running sensitive things like the
OS... An OS tripping up because of a flipped bit could cost a
hell of a lot of work and if you were unlucky, a lot of downtime
too.
Cheers,
Rupert
Rupert Pigott
> Rupert Pigott <dark.try-eati...@btinternet.com> wrote:
> >"J Ahlstrom" <jahl...@cisco.com> wrote in message
> >news:3CFD00B1...@cisco.com...
> >> Parity is for farmers.
> >> attrib S Cray
> >
> >I'd be spinning in my grave is I had that attributed to
> >me... Even in this modern day & age... Bit flips still
> >happen and the larger the system the more likely...
>
> I would not worry about it. I doubt S. did.
>
> His about face follow on was
> Even farmers buy computers.
As it happens my favourite processor of all time, the INMOS
Transputer went through a similar about face. Check out the
1989 databook and see if you see any parity on the memory
I/Fs... A special T4xx series part was made for a customer
who felt very strongly about it. As it happens I made an
about turn on my "We don't need no stinkin' parity" position
when the figures were presented. :P
To be fair to Seymour the -1 used ECL logic which probably
means differential signals which should eliminate cross talk,
which must be a killer on big fast-clocked systems full of
wiring... However the ECL memories themselves were probably
quite capable of flipping bits on their own... I guess I'm
extremely unlikely to get hold of MTB-BitFlip on the Cray-1
1024x1 ECL memories... I'd like to actually get a feel for
the risk factor there before I totally condemn Seymour. :)
I'm hunting for some stats now. Curious. :)
[SNIP]
Cheers,
Rupert
artie
the "To," "Cc," and "Newsgroups" headers for details. ]]
In article <d266ec61.02060...@posting.google.com>, Tom Uban
<tu...@ubanproductions.com> wrote:
Thanks! I'll still keep looking for a printed copy, but this is great
news!
namaste-
CBFalconer
>
... snip about parity and ECC etc ...
>
> To be fair to Seymour the -1 used ECL logic which probably
> means differential signals which should eliminate cross talk,
> which must be a killer on big fast-clocked systems full of
> wiring... However the ECL memories themselves were probably
> quite capable of flipping bits on their own... I guess I'm
> extremely unlikely to get hold of MTB-BitFlip on the Cray-1
> 1024x1 ECL memories... I'd like to actually get a feel for
> the risk factor there before I totally condemn Seymour. :)
Has anyone got any URLs for modern statistics on failures in
typical PC memory systems? I keep telling people to buy ECC
systems, with only nebulous statistics to back it up. Something
that also shows failure vs altitude (cosmic rays) would be nice.
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
CBFalconer
Should someone ever re-scan it, it would be pleasant to have it at
one page per sheet, so the result can be printed out in booklet
form. I know of no way of separating the facing pages in the pdf
file. It was well worth the half-hour download :-)
Rupert Pigott
news:3CFD93C2...@yahoo.com...
> Has anyone got any URLs for modern statistics on failures in
> typical PC memory systems? I keep telling people to buy ECC
> systems, with only nebulous statistics to back it up. Something
> that also shows failure vs altitude (cosmic rays) would be nice.
Pick up a memory databook, they should have stats in them,
the ones I was using back in '90 certainly did. You can
usually get them by ringing up a manufacturer and just
asking for it.
Actually it isn' *just* the memories you're trying to check
with error detection, it's the entire end-to-end datapath.
It used to be the case that the high-end RISC chips had ECC
on all their major busses and cache too... Don't know if
that is still the case or whether the x86 has caught up with
that yet...
Cheers,
Rupert
Rupert Pigott
[SNIP]
> file. It was well worth the half-hour download :-)
Damn right, I'm enjoying it. Thanks for scanning it ! :)
Cheers,
Rupert
Douglas H. Quebbeman
> >
> > After being granted permission to copy, scan, and make available
> > this book by Mr. Thornton, who is the current holder of the rights,
> > a scan is now available at the following location:
> >
> > http://www.spies.com/aek/pdf/cdc/DesignOfAComputer_CDC6600.pdf
> >
> > A copy of the correspondence pertaining to permissions can be found
> > in the last two pages of the scan.
> >
> > Please be considerate to the author and do not abuse this gift.
>
> Should someone ever re-scan it, it would be pleasant to have it at
> one page per sheet, so the result can be printed out in booklet
> form. I know of no way of separating the facing pages in the pdf
> file. It was well worth the half-hour download :-)
A single-page-per-sheet version is in the work queue...
-dq
CBFalconer
> > typical PC memory systems? I keep telling people to buy ECC
> > systems, with only nebulous statistics to back it up. Something
> > that also shows failure vs altitude (cosmic rays) would be nice.
>
> Pick up a memory databook, they should have stats in them,
> the ones I was using back in '90 certainly did. You can
> usually get them by ringing up a manufacturer and just
> asking for it.
>
> Actually it isn' *just* the memories you're trying to check
> with error detection, it's the entire end-to-end datapath.
> It used to be the case that the high-end RISC chips had ECC
> on all their major busses and cache too... Don't know if
> that is still the case or whether the x86 has caught up with
> that yet...
Agreed, but I am looking for a URL to quote to idjits who squeal
that money is better spent on faster CPUs overclocked into
unreliability and the heat death, so that they can save time to
spend on later complete reloads from fouled backups, thus allowing
them to howl about unreliable software.
CBFalconer
"Douglas H. Quebbeman" wrote:
Glad to hear it. When ready I would appreciate an e-mail advice,
as I might well miss anything posted here.
BTW, reply-to fields are immune to normal spammer techniques,
while from: fields are harvested readily. Similarly text fields
require the whole message to harvest, rather than the readily
available headers (which don't include the reply-to field). I
hope I have transversed those thickets correctly.
Rupert Pigott
> Rupert Pigott wrote:
> > "CBFalconer" <cbfal...@yahoo.com> wrote in message
> >
> > > Has anyone got any URLs for modern statistics on failures in
> > > typical PC memory systems? I keep telling people to buy ECC
> > > systems, with only nebulous statistics to back it up. Something
> > > that also shows failure vs altitude (cosmic rays) would be nice.
> >
> > Pick up a memory databook, they should have stats in them,
> > the ones I was using back in '90 certainly did. You can
> > usually get them by ringing up a manufacturer and just
> > asking for it.
> >
> > Actually it isn' *just* the memories you're trying to check
> > with error detection, it's the entire end-to-end datapath.
> > It used to be the case that the high-end RISC chips had ECC
> > on all their major busses and cache too... Don't know if
> > that is still the case or whether the x86 has caught up with
> > that yet...
>
> Agreed, but I am looking for a URL to quote to idjits who squeal
> that money is better spent on faster CPUs overclocked into
> unreliability and the heat death, so that they can save time to
> spend on later complete reloads from fouled backups, thus allowing
> them to howl about unreliable software.
Best thing I've found so far is a research paper by Boeing
which even includes figures for CRAY Y-MP8... :)
It's going to take a while for me to digest this one. Out
of date, but very interesting reading ! Turns out that
CRAYs ended up with SECDED and then DECMED parity checking
too... I reckon those machines with their huge memories
must have made great memory failure rate test beds. :P
I'm still looking for some data in web-published datasheets
and so far I've come up empty... Can't believe that... I
certainly don't believe that the error rates are so low
that they aren't worth publishing...
Cheers,
Rupert
Rupert Pigott
news:adlesi$ail$1...@knossos.btinternet.com...[SNIP]
> > Agreed, but I am looking for a URL to quote to idjits who squeal
> > that money is better spent on faster CPUs overclocked into
> > unreliability and the heat death, so that they can save time to
> > spend on later complete reloads from fouled backups, thus allowing
> > them to howl about unreliable software.
>
> Best thing I've found so far is a research paper by Boeing
> which even includes figures for CRAY Y-MP8... :)
[SNIP]
Couple of URLS :
http://www.boeing.com/assocproducts/radiationlab/publications/SEU_at_Ground_
Level.pdf
http://download.micron.com/pdf/technotes/DT28.pdf
The Micron one argues that parity is needed for the
busses not for the memories themselves... They
specifically mentioned checking for the address
busses... I got some warm fuzzies from the SER's of
DRAMs from 6 years ago, but nothing more recent...
It would appear that there was a stronger argument
parity on CRAY-1's than there is on modern PCs. In
the light of the Micron tech note I'm not sure about
the utility of ECC in PCs *unless* all the datapaths
support it. Certainly the x86 architecture has room
for it, maybe this is why people pony up horrendous
amounts of money for Xeons... Can't be for the SMP
performance...
Cheers,
Rupert
kesi...@math.ttu.edu
[everything save the sig snipped]
: Parity is for farmers.
: attrib S Cray
I don't get it. Why farmers?
==Jake
J Ahlstrom
During the 50s and 60s the federal government
support for farmers as based at least in part on
the notion of 'parity' of income or price that farmers should
receive for their work or products.
Al Kossow
http://usinfo.state.gov/products/pubs/oecon/chap8.htm
"Upon his inauguration as president in 1933, President Franklin D.
Roosevelt moved national agricultural policy far beyond the Hoover
initiative. Roosevelt proposed, and Congress approved, laws designed to
raise farm prices by limiting production. The government also adopted a
system of price supports that guaranteed farmers a "parity" price roughly
equal to what prices should be during favorable market times. In years of
overproduction, when crop prices fell below the parity level, the
government agreed to buy the excess."
Eugene Miya
Rupert Pigott <dark.try-eati...@btinternet.com> wrote:
>"Eugene Miya" <eug...@cse.ucsc.edu> wrote in message
>news:3cfd1c39$1...@news.ucsc.edu...
>> In article <adj5u3$4c6$1...@knossos.btinternet.com>,
>> Rupert Pigott <dark.try-eati...@btinternet.com> wrote:
>> >"J Ahlstrom" <jahl...@cisco.com> wrote in message
>> >news:3CFD00B1...@cisco.com...
>> >> Parity is for farmers.
>> >> attrib S Cray
>> >
>> >I'd be spinning in my grave is I had that attributed to
>> >me... Even in this modern day & age... Bit flips still
>> >happen and the larger the system the more likely...
>>
>> I would not worry about it. I doubt S. did.
>
>Heh, you've never done the MTBF calcs for a real app
>using a 4Mbyte DRAM array in the 1990s have you ?
No I have only helped designed R/W heads for WInchesters and credit card
readers.
Real apps, I have a few.
Toy apps are far more fun.
>I should repeat those for a 4Gbyte DDRAM array nowadays
>and compare notes... :)
>
>> His about face follow on was
>> Even farmers buy computers.
>>
>> And he said that all before the Cray-1.
>>
>> Still an amazing accomplishment.
>
>Sure, but not much use in production if you can't trust
>the thing to deliver correct results repeatably. Well,
>I'm being a bit harsh, you could use it for keeping you
>warm in winter.
MN and WI can be pretty cold in winter.
Hind sight is wondergul for many after Seymour's passing.
He was a hard act for most engineers to follow.
Eugene Miya
I know Cray-1 logic was ECL, but I thought the main memory was BiPolar.
I know who to ask, but I'm headed off to vacation.
I'm a software guy. I let others deal with the hardware.
Kent Olsen
> Even if you're using such an algorithm, I still think that it
> would be prudent to have an ECC protected region for instruction
> and critical data storage for running sensitive things like the
> OS... An OS tripping up because of a flipped bit could cost a
> hell of a lot of work and if you were unlucky, a lot of downtime
> too.
I've seen that very thing happen several times.
On a 6000 series machine (the subject of Thornton's book) I saw the
results of a PP dropping a bit in the A register. The PP was supposed
to write several words of "MWMWMWMWMWMW" (the banner page demark) but
the A register had flipped the sign bit. The result was an entire
computer with every word of CM containing "MWMWMWMWMW". (It was
pretty easy to convince the CE that we had a hardware problem!)
Kent
CBFalconer
Something to do with crop price supports of the day. Since turned
out to be one more way of passing general tax revenue into the
hands of large food corporations, who then use a significant
proportion thereof advertising how public spirited they are, and
another large portion funding lobbyists, bribes, stock options,
and golden parachutes. I don't get it (the place at the trough).
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> To be fair to Seymour the -1 used ECL logic which probably
> means differential signals which should eliminate cross talk,
> which must be a killer on big fast-clocked systems full of
> wiring... However the ECL memories themselves were probably
> quite capable of flipping bits on their own... I guess I'm
> extremely unlikely to get hold of MTB-BitFlip on the Cray-1
> 1024x1 ECL memories... I'd like to actually get a feel for
> the risk factor there before I totally condemn Seymour. :)
>
overriding concern. More memory, faster components,
shorter wire lengths, and anything else he could
think of to speed things along... Even if it takes
exotic cooling methods...if it goes faster, he would
be interested IMHO.
--
+-------------------------------------------------------------+
| Charles and Francis Richmond <rich...@plano.net> |
+-------------------------------------------------------------+
Charles Richmond
>
> [snip...] [snip...] [snip...]
>
> Agreed, but I am looking for a URL to quote to idjits who squeal
> that money is better spent on faster CPUs overclocked into
> unreliability and the heat death, so that they can save time to
> spend on later complete reloads from fouled backups, thus allowing
> them to howl about unreliable software.
>
liquid nitrogen... (;-)) That'll chill 'em out!!!
Heinz W. Wiggeshoff
> No heat death!!! No heat death!!! Just submerge the CPU's in
> liquid nitrogen... (;-)) That'll chill 'em out!!!
Shrinks them too.
Rupert Pigott
news:adlvjc$dug$1...@freenet9.carleton.ca...
Doesn't do the pads or bonding any good either IIRC. The
safer method is gradual lowering into the vapour coming
off a tray of LN2 so you don't get the thermal stress...
As it happens I was trolling the ECL databooks recently
(in search of SERs for ECL 1Kx1 memories) and I noticed
that they usually got slower performance as they went
below -55. :)
Cheers,
Rupert
Rupert Pigott
[SNIP]
> I know Cray-1 logic was ECL, but I thought the main memory was BiPolar.
There was a 100k ECL series 1kx1 part, I think it was
the 100415. It looks pretty close to the CRAY-1 part in
terms of performance (from what I read anyways). The
closest I can find at the moment is a 1kx4 part at
http://www.micrel.com/product-info/products/SY10-100101474.html
I like ECL. Neat stuff, totally insane on the power
consumption front and fantastically fast, but it also
has excellent noise immunity... I enjoyed trolling
through the ECL databooks again, I remember drooling
over them years back when I new even less than I do
now... :)
ECL still looks awesome now, although it's frighteningly
expensive to build with. :)
Cheers,
Rupert
Douglas H. Quebbeman
> >Sure, but not much use in production if you can't trust
> >the thing to deliver correct results repeatably. Well,
> >I'm being a bit harsh, you could use it for keeping you
> >warm in winter.
>
> MN and WI can be pretty cold in winter.
>
> Hind sight is wondergul for many after Seymour's passing.
> He was a hard act for most engineers to follow.
FWIW, the follow-on to the 6000/Cyber 70 series, the Cyber 170
series, did use SECDED (single-error correction, double-error
detection) memory subsystems.
-doug q
Douglas H. Quebbeman
> of date, but very interesting reading ! Turns out that
> CRAYs ended up with SECDED and then DECMED parity checking
> too... I reckon those machines with their huge memories
> must have made great memory failure rate test beds. :P
The Cyber 170 series also used SECDED memory subsystems.
-doug q
J. Otto Tennant
> ==Jake
I tend to suspect many quotes attributed to S. Cray.
"Parity" was (and perhaps still is) a method of subsidizing farmers. It
makes no more sense than the "Eau Claire Rule" (which, to our eternal
shame, is still in effect.)
In any case, Dr. Cray changed his mind. The CRAY-1 SN-1 did not have
parity; the CRAY-1 SN-3 had SECDED.
If the quotation is true, I think (and this is my personal opinion, and
I am just a user, not a hardware or software engineer) that it made
sense at the time. "Core" memory just did not fail very often, and the
parity bit was a waste of hardware.
When I was working with machines using core memory, I only saw two solid
instances of a core memory failure.
The first occured when core memory cost $1/byte. A bit in transient
memory failed solid at "0". My "management" was not willing to blow
$5000 to replace the failed module. It occurred to me that the system
had about 16K of resident memory (that would be 8 memory modules.) I
looked through the assembly source code for the resident memory and
found an instruction where the "0" was part of it.
I told the hardware guy to exchange the two memory modules, and he was
astonished that the machine worked happily. Of course, the failed memory
module wore a red tag for two years. Parity is for farmers.
The second occurred when I put a "patch" into a kernel to catch a bug.
The "patch" put the kernel in a very tight loop when the error occurred.
I put the patch in on a Friday night. I planned to check the machine on
Saturday, but I got a wee bit drunk.
The patch worked as I had intended, but, on Monday morning when I
dragged my weary body into work, the patch had burned out a couple of
cores.
The point of this message is that "core" memory is very reliable, and
you do not really need parity for core memory.
There is the anecdotal story of a "half-set core", but that only happens
when power fails --- and you have to re-boot the machine anyway.
Anyway ....
--
J.Otto Tennant jo...@pobox.com
Forsan et haec olim meminisse juvabit.
Charter Member of the Vast Right Wing Conspiracy
Heinz W. Wiggeshoff
...
> As it happens I was trolling the ECL databooks recently
> (in search of SERs for ECL 1Kx1 memories) and I noticed
> that they usually got slower performance as they went
> below -55. :)
Like people, electrons don't move so fast in the cold either.
This explains the Borialas - they move so slowly you can see them.
And why lights are so dim in Ant/Arctic stations.
Rupert Pigott
news:3cfeac37$1...@news.iglou.com...
Ugh, missing posts again... Second hand it is...
> > >Sure, but not much use in production if you can't trust
> > >the thing to deliver correct results repeatably. Well,
> > >I'm being a bit harsh, you could use it for keeping you
> > >warm in winter.
> >
> > MN and WI can be pretty cold in winter.
Hehe, yeah. It didn't go unnoticed that Seymour's machines
seemed to be heating system friendly. :P
> > Hind sight is wondergul for many after Seymour's passing.
> > He was a hard act for most engineers to follow.
Of course, the old 20/20 is the best tool in the trade...
Learning from mistakes... Yes, I do believe he was a great
engineer. However Parity and the reasons for using it
were not new even back then. If I was Seymour I would be
annoyed at what all that extra circuitry was going to do
to my datapaths and lovely clean architecture...
> FWIW, the follow-on to the 6000/Cyber 70 series, the Cyber 170
> series, did use SECDED (single-error correction, double-error
> detection) memory subsystems.
Large machines which don't use parity seem to be rare.
Cheers,
Rupert
Rupert Pigott
LOL, I hope there aren't any EE students reading that.
Cheers,
Rupert
Heinz W. Wiggeshoff
>
> LOL, I hope there aren't any EE students reading that.
Reading? Usenet? If memory serves, they're out drinking.
(In my next exposition, I'll relate what I read about freezing
light. Now _that's_ neat. And just as suitable for here as
that multiverse poop. Plus, I didn't top post!)
Charles Richmond
Toby Thain
> "J Ahlstrom" <jahl...@cisco.com> wrote in message
> news:3CFD00B1...@cisco.com...
>
>>Parity is for farmers.
>> attrib S Cray
>
>
>
> I'd be spinning in my grave is I had that attributed to
there's three right there!
T
> me... Even in this modern day & age... Bit flips still
> happen and the larger the system the more likely...
>
> Cheers,
> Rupert
>
>
Eric S. Harris
>
> Tom:
>
> Please express my great appreciation to Mr Thornon
> that he has done this. The book is a classic of form and
> substance and required reading for anyone interested
> in computer architecture at a deeper level than
> bar room bets and news group babble.
>
> John K Ahlstrom
> --
> Parity is for farmers.
> attrib S Cray
Another possibly apocryphal anecdote.
Some years later he reconsidered his position, and included parity (or possibly
even error-correcting bits) in a machine. (I know SECDED did appear, by and
by. Cyber series?) When asked about the change in position, he quipped that
more farmers were using computers now.
I don't know if he really said that, but I really heard the story. Perhaps a
former coworker or instructor or VIM attendee told me.
Speaking of which...
If you know me, but didn't just get an e-mail from me: Do you have e-mail
addresses for our mutual acquaintances from CDC Cyber days? Can I have yours?
I don't have one for a whole bunch of people I'd like to get back in touch with.
If so, please forward this on to them. They might enjoy the "parity" quip, or
be willing to 'fess up to telling it.
In any event, I'd like to get back in touch. Maybe this will be the year I
start sending out Christmas / Hanukkah / Solstice / whatever cards again.
Another CDC story.
A visitor from another CDC site was being shown our site, including a Cyber
176. (I think that was the machine.) He was impressed, and said "So you found
a way to get it to run with the door closed. We've had to leave the door on
ours open, or it would crash. A lot."
Afterward, we also kept our Cyber's open; we'd been having frequent and
mysterious crashes before our out-of-town visitor stopped by. Seemed to do the
trick.
I wasn't there, so some details of the story may be wrong, but that was the
gist. -Eric S.
Rupert Pigott
news:3CFE9513...@ev1.net...
> Rupert Pigott wrote:
> >
> > [snip...] [snip...] [snip...]
> >
> > To be fair to Seymour the -1 used ECL logic which probably
> > means differential signals which should eliminate cross talk,
> > which must be a killer on big fast-clocked systems full of
> > wiring... However the ECL memories themselves were probably
> > quite capable of flipping bits on their own... I guess I'm
> > extremely unlikely to get hold of MTB-BitFlip on the Cray-1
> > 1024x1 ECL memories... I'd like to actually get a feel for
> > the risk factor there before I totally condemn Seymour. :)
> >
> Seymour Cray had a "need for speed"...that was his
> overriding concern. More memory, faster components,
> shorter wire lengths, and anything else he could
> think of to speed things along... Even if it takes
> exotic cooling methods...if it goes faster, he would
> be interested IMHO.
Well, yeah of course, but it's still no bloody use if
it produces duff results. It's like a jolly fast
racing car, it needs to cross the line largely in one
piece having covered the full race distance. Rarely
do cars win having suffered a wheelnut falling off
at any part in the race. ;)
Cheers,
Rupert
Ignatios Souvatzis
"Douglas H. Quebbeman" <do...@ixnyamspayiglou.com> writes:
> FWIW, the follow-on to the 6000/Cyber 70 series, the Cyber 170
> series, did use SECDED (single-error correction, double-error
> detection) memory subsystems.
I've used a '172.
-is