it supports 4gb of memory.
of non-ECC memory, so nice terminal, bad server
Any recommendations of similar hardware which does support SECDED ECC?
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 the cpu)
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
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
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. It
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...
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 the time
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 the time
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 ratio
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
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
On Thu, Feb 18, 2010 at 10:26 AM, matt maht-9f...@maht0x0r.net 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
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't
On Feb 18, 2010, at 1:31 PM, ron minnich rminn...@gmail.com wrote:
On Thu, Feb 18, 2010 at 10:26 AM, matt maht-9f...@maht0x0r.net
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
On Thu, Feb 18, 2010 at 10:31 AM, ron minnich rminn...@gmail.com wrote:
On Thu, Feb 18, 2010 at 10:26 AM, matt maht-9f...@maht0x0r.net 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
On Thu, Feb 18, 2010 at 10:39 AM, erik quanstrom
quans...@labs.coraid.com 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
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
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 this be
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
On 18 February 2010 22:38, erik quanstrom quans...@labs.coraid.com 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
On 19 February 2010 09:38, erik quanstrom quans...@labs.coraid.com 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
On Thu, Feb 18, 2010 at 3:12 PM, Adrian Tritschler a...@ajft.org 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
22 matches
Mail list logo
