>>>>> "c" == chris <no-re...@opensolaris.org> writes: >>>>> "hk" == Haudy Kazemi <kaze0...@umn.edu> writes:
c> why would anyone use something called basic? But there must be
c> a catch if they provided several ECC support modes.
They are just taiwanese. They have no clue wtf they are doing and do
not care about quality since their customers don't have any memory
past six months, and anyway if they get a bad reputation they'll just
sell the same crap under a different brand name. They are just trying
to ship kit for gamers as quickly as possible. They view the design
of their box and website and little bubbly slogan blobs as their key
distinguishing asset over their competitors, not what's inside. Do
not try to reason with these people who have zero respect for you, and
certainly do not trust them to do something ``reasonable'' and then
try to work out what they've not documented based on blind faith in an
orderly world with competent stewardship.
Read jaakko's script that I posted and set the timer to scrub the
amount of memory you have about once a day. The script will give you
status, showing the current address being scrubbed, so you can watch
the rate at which the counter increases, and also watch the counter
wrap around to determine the number of zeroes it has hacked off from
the size of your memory. With a couple observations spaced 10min
apart, plus a series of observations each spaced 4 hours apart, you
can convert the microseconds you feed to the script into
hours-per-complete-pass and accomplish this. If you really care that
much. I didn't---just made sure it wasn't crazy.
It isn't really that important anyway---you should not think about it
so much. I jsut blundered through it. I'm spending more time writign
about it than doing it. it is just a bunch of toy knobs for you to
play with. The important thing is, will it actually correct errors?
will the OS count the errors? will it localize them to a DIMM? since
the L2 caches are 10x the size they used to be and etched
smaller/more-sensitive will ECC also work on the on-chip cache and get
counted and reported distinct from DIMM's, or not? All of these are
more important than whether it does any scrubbing at all, much less
the specific timing of the scrubbing.
I bought four different boards on purpose to get a cross-section of
crappyness, and the arena is incredibly stabby. There is all kinds of
stuff in the BSoS like DIMM powerdown and C1E support that probably
doesn't work at all. One of these nvidia-northbridge boards, the
audio controller showed up on a different interrupt every time I
booted it. Some other board, you needed an actual physical floppy
disk to update the BIOS---pxeboot/memdisk just froze, even though it
works for everything else I've tried. Who even HAS a floppy disk?
Don't get distracted playing with their stupid fisher price knobs like
an overclocker. Just flip the ECC thing on and forget about it. What
jaakko demonstrates is that support for AMD ECC probably belongs in
the OS or bootloader anyway, since it's entirely in the CPU and not
integrator-specific and the people who write OS's are less idiotic
than these ship-and-forget BIOS people and besides the error reporting
needs to be in the OS anyway, which is a more complicated piece, so
relying on someone else to ``turn it on'' for you when turning it on
boils down to a couple setpci lines in a shell script is completely
retarded.
hk> DDR3: $108 for Crucial 6GB (3 x 2GB) 240-Pin DDR3 SDRAM ECC
yeah, but for 4GB parts it's not a 12% difference any more. It's raep.
pgp1PpZs2xc3p.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
