> Maybe Supermicro X8SIL
obviously not an atom, but
> Don't know how well this card is supported by Plan 9, but
i have tested it and everything works fine. of course
(repeating the op) the xeon processor is required to
get ecc, since the memory controller is part of the cpu.
and the core iX ver
Maybe Supermicro X8SIL
Don't know how well this card is supported by Plan 9, but
it has a µ-ATX form factor and supports DDR3 ECC if you
couple it with a Xeon 34xx in the LGA1156 socket. The Quad
Core (no HT) Xeon L3426 is listed to have a TDP of 45 Watts.
Albert Skye wrote:
it supports 4gb of
On Mon Mar 8 13:36:54 EST 2010, mistl...@yahoo.co.uk wrote:
> >> it supports 4gb of memory.
> > of non-ECC memory, so nice terminal, bad server
>
> Any recommendations of similar hardware which does support SECDED ECC?
the memory controller is integrated into the cpu
package (though not th
>> it supports 4gb of memory.
> of non-ECC memory, so nice terminal, bad server
Any recommendations of similar hardware which does support SECDED ECC?
> Actually, even adding it in memory isn't that easy. In the old days,
> a simple Hamming code was good enough because each bit in a word lived
> on a different chip. Now memory chips are wider and so the code has
> to account for multi-bit errors (flipping of bits is not independent).
Indeed...
On Feb 21, 2:48Â pm, davide...@cs.cmu.edu (Dave Eckhardt) wrote:
> * Bits were flipping pretty often. Â I think we got 10-ish events
> per day.
TLB bits are not like DRAM bits. They were surely static cells, built
for speed and functionality (CAM) not density. The cells would be
quite large. I
>> "Back in the old days", a lot of VAX-11/750's running BSD Unix
>> crashed because of parity errors in their TLB's. 750's running
>> VMS "didn't have this problem", because VMS would silently work
>> around it; BSD grew that code--see, for example, <2...@astrovax.uucp>.
>> Then bits could flip a
> "Back in the old days", a lot of VAX-11/750's running BSD Unix
> crashed because of parity errors in their TLB's. 750's running
> VMS "didn't have this problem", because VMS would silently work
> around it; BSD grew that code--see, for example, <2...@astrovax.uucp>.
> Then bits could flip all th
> You'd need to look at fraction of total that is data vs. code,
> then at fraction of total code that is going to cause hurt if
> flipped. This stuff can have numbers attached.
>
> Here's an example from my world. 1 MB of code, 32 MB of kernel,
> and 2GB minus that of data. This is a lower end
On Thu, Feb 18, 2010 at 3:12 PM, Adrian Tritschler wrote:
> Flips in code are more likely to cause crashes, but still not
> guaranteed.
You'd need to look at fraction of total that is data vs. code, then at
fraction of total code that is going to cause hurt if flipped. This
stuff can have number
On 19 February 2010 09:38, erik quanstrom wrote:
>> There is no mechanism which directly translates bit flips
>> to crashes! The bad case is actually a corruption which
>> does *not* cause a crash, but is written to disk. How
> indirection? executable code being turned into illegal
> instructi
On 18 February 2010 22:38, erik quanstrom wrote:
> indirection? executable code being turned into illegal
> instructions? it's not 100% efficiency but it will translate
> flipped bits into crashes.
i'm interested - does anyone know what a typical relative
percentage of pointer- vs. non-pointer-
> There is no mechanism which directly translates bit flips
> to crashes! The bad case is actually a corruption which
> does *not* cause a crash, but is written to disk. How
indirection? executable code being turned into illegal
instructions? it's not 100% efficiency but it will translate
flip
> i have been running a amd64 machine as a cpu server
> for 2 years. it uses standard ddr2 memory. i have not
> seen any unexplained crashes or reboots during this time.
>
> at work, i have been running 5 un-ecc'd machines for
> 3 years. also no unexplained crahses or reboots.
>
> how could th
> in many cases it's all about location. Where I used to live, 7200 feet
> up, it was a huge issue. Where you live, i am assuming close to sea
> level, and with a small number of machines, the statistics say that
> you're unlikely to see it. But I would not want to take several
> thousand of your m
On Thu, Feb 18, 2010 at 10:39 AM, erik quanstrom
wrote:
> while i agree in general that ecc is a good idea, i can't
> subscribe to predictions that seem so far from real-world
> experience.
in many cases it's all about location. Where I used to live, 7200 feet
up, it was a huge issue. Where you
On Thu, Feb 18, 2010 at 10:31 AM, ron minnich wrote:
> On Thu, Feb 18, 2010 at 10:26 AM, matt wrote:
> >
> >
> >> it supports 4gb of memory.
> >
> > of non-ECC memory, so nice terminal, bad server
> >
> >
> > "the probability of having at least one bit error in 4 gigabyes of memory
> at
> > sea
On Feb 18, 2010, at 1:31 PM, ron minnich wrote:
On Thu, Feb 18, 2010 at 10:26 AM, matt
wrote:
it supports 4gb of memory.
of non-ECC memory, so nice terminal, bad server
"the probability of having at least one bit error in 4 gigabyes of
memory at
sea level on planet Earth in 72 h
"Also avoid using your laptop [...] near radioactive areas (Three Mile
Island, Chernobyl, Ground Zero)." - from the follow up article.
>
>
>> it supports 4gb of memory.
>>
>>
> of non-ECC memory, so nice terminal, bad server
>
>
> "the probability of having at least one bit error in 4 gigabyes of
> of non-ECC memory, so nice terminal, bad server
>
>
> "the probability of having at least one bit error in 4 gigabyes of
> memory at sea level on planet Earth in 72 hours is over 95%."
>
>
> http://lambda-diode.com/opinion/ecc-memory
while i agree in general that ecc is a good idea, i can'
On Thu, Feb 18, 2010 at 10:26 AM, matt wrote:
>
>
>> it supports 4gb of memory.
>
> of non-ECC memory, so nice terminal, bad server
>
>
> "the probability of having at least one bit error in 4 gigabyes of memory at
> sea level on planet Earth in 72 hours is over 95%."
humorous and true story. T
it supports 4gb of memory.
of non-ECC memory, so nice terminal, bad server
"the probability of having at least one bit error in 4 gigabyes of
memory at sea level on planet Earth in 72 hours is over 95%."
http://lambda-diode.com/opinion/ecc-memory
it seems that the pineview atom can be
a great plan 9 machine. i've got a
x7spa-h atom d510 motherboard with
2 x 82574 gbe, etc. it supports 4gb
of memory. it "just works".
could support amd64, too (dx 0x2000
indicates 64-bit support)
; aux/cpuid -n 0x8001
23 matches
Mail list logo
