Toyotas and neutrons
robert.stratton at stratton.net
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 ccr.org> 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!
> wb5mmb wrote:
>> (2.3 meg pdf)
>> Tacos mailing list
>> Tacos at amrad.org
> Tacos mailing list
> Tacos at amrad.org
"Of course it's hard!
If it was easy, we'd be buying it from somebody else!"
Tacos mailing list
Tacos at amrad.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tacos