A8V Deluxe memory settings

G

Guest

Guest
Archived from groups: alt.comp.periphs.mainboard.asus (More info?)

A8V Deluxe memory settings in bios has "Scrub" settings disabled.
Should these be enabled for better performance ?
2 512 pc3200 in Dual Channel Mode.

Thanks
Ron
 

Paul

Splendid
Mar 30, 2004
5,267
0
25,780
Archived from groups: alt.comp.periphs.mainboard.asus (More info?)

In article <fG5vd.2424$%p1.254409@news20.bellglobal.com>, "RonK"
<I'mnuts@home.com> wrote:

> A8V Deluxe memory settings in bios has "Scrub" settings disabled.
> Should these be enabled for better performance ?
> 2 512 pc3200 in Dual Channel Mode.
>
> Thanks
> Ron

Some memory controllers support ECC error detection and correction.
You need DIMMs with a 72 bit wide data path (an ECC DIMM) to talk
to the 72 bit wide memory bus on an ECC equipped memory controller.

Now, that being said, there are two ways for ECC to be used.

When ECC is enabled, it means on every write, a whole 72 bit
word, with a valid ECC, are written to memory. If an architecture
supports byte or half word operands, to update a location in
memory, while ECC is enabled, means reading the whole 72 bit
quantity, replacing the section of the word to be updated,
then writing the data back. (A read-modify-write cycle, instead
of just a write cycle, when ECC is enabled. That is needed in
order to update the ECC byte in the memory location.)

Depending on how often the archtecture does that, determines
how much performance is lost while using ECC.

A second way ECC can be used, is to "audit" the contents of
the entire memory. When "scrub" is enabled, the memory
controller does some independent accesses of the memory, in
an incrementing address pattern. If a memory read error is
correctable, the memory controller writes back the content
of the memory, and attempts to correct the data, based on the
error syndrome. If the memory read error is uncorrectable,
then the scrubber could report the serious error condition
to the OS (and I don't know how a scrubbed memory error is
treated, as the memory being tested might not currently be
used by the OS). By moving through memory, and correcting
the easy to correct errors, the error rate of the memory
is reduced. In other words, when the OS fetches from a
scrubbed location later, the OS could be blissfully unaware
that the location had a simple error in it previously, since
the scrubber already corrected it. This is good if the memory
errors are caused by alpha radiation in the memory chip
packaging (not as much of an issue as it once was).

This is a useful function in mission critical server
applications, and presumably ECC was added to the architecture
for the sake of the Opteron family and its server
applications. Whether it buys you anything in a desktop
application is questionable. For a desktop, if you've
already tested the computer with memtest86 and Prime95,
your chances of seeing an error are pretty slim. You are
likely to be rebooting often enough, that error accumulation
is a non issue.

Before enabling scrubbing, you may want to do more research
on some of the private forums, as scrubbing implementations
haven't always been perfect. I don't know how well the
Athlon64 works, in this regard (as the memory controller
is integrated in the processor).

In summary:

1) ECC must be enabled, for scrubbing to work.
2) ECC robs performance, when an architecture supports byte
or half word write, by requiring the use of read-modify-write
cycles. The added delay for ECC calculations is normally
hidden by the deep pipelines in modern processors. I don't
know how this affects Athlon64.
3) Scrubbing removes single errors from memory words
autonomously. Correctable or uncorrectable but detectable
errors can be counted, or each one can cause an interrupt
and be reported immediately to the OS.
4) Scrubbing should be opportunistic, and only do cycles
when the CPU is not using the memory. But, there are
bound to be situations, where the access latency for the
processor is being increased, as the memory is currently
finishing a scrubber induced memory cycle. An application
benchmark, like Super_PI, may help you determine how good
the implementation of the feature happens to be. (Run
Super_PI with and without scrubbing, to see how much
interference there is between scrubbing and normal CPU
access.)
5) I have no idea which OSes support ECC and/or scrubbing. A
server OS is more likely to do a good job at this, than
a desktop OS.

Unless you are running a server, I would leave it disabled.

HTH,
Paul