Toyotas and neutrons

Robert Stratton robert.stratton at
Wed Mar 24 14:26:55 CDT 2010

It wouldn't be a bad topic for a letter to the Defense Science Board. 

-- Bob S.
On Mar 24, 2010 12:35, Mike O'Dell <mo at> wrote: 

and people don't understand why i'm incensed that Intel

has disabled use of ECC by the "desktop" Nahalem processors

(i5, i7,i9). the "server" processors have ECC and Intel's

configuration notes say that a server REALLY SHOULD use ECC.

Meanwhile, the FAQ for the i7 states that it doesn't have ECC

*because desktops don't usually run long enough to have a problem*.

One big reason for the ECC difference is that it is about the ONLY

difference between the i7s and the Xeon 5500s other than the price.

That is nothing short of criminal malfeasance - using the unreliability

of Windows to charge more for a processor because the users won't

be able to tell the difference as to the cause.

The busses are much, much faster, the signal margins much smaller,

the memory parts are massively more dense and the charge in the

capacitor cells is a small fraction of previous DRAMS.

This is a recipe for DISASTER.

What's more troubling is that the "COTS Journal", which is about

using off-the-shelf hardware in military systems, now has ads for

i7-based boards for embedded applications. not that long ago,

mil-spec systems required ECC for obvious reasons. now these

flying-on-a-wing-and-a-prayer processors are going to get put

into military systems? THIS IS MADNESS.

I'd raise a genuine stink about this if I had any idea how to do it

such that it might do some good.


On 3/23/10 11:27 PM, John Teller wrote:

> Writing as much code as I have for satellite systems, most of which had

> to live without radiation hardened and/or EDAC memory, I just got used

> to not trusting that stuff I had written to memory wouldn't stay that way.


> It's served me in good stead while working with some X parts we recently

> obtained from a supplier that came with an undisclosed read/write

> problem. The first batch of production ready parts do not have this

> problem. I was able to deal with the glitch-prone X parts effectively

> enough to provide our beta customers with products they could start

> testing with. We're not planning on removing that code for the fixed parts!


> ---JST



> wb5mmb wrote:







>> (2.3 meg pdf)




>> _______________________________________________

>> Tacos mailing list

>> Tacos at



> _______________________________________________

> Tacos mailing list

> Tacos at



"Of course it's hard!

If it was easy, we'd be buying it from somebody else!"


Tacos mailing list

Tacos at

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Tacos mailing list