Re: Isn't Command Rate a "memory setting?"
- From: nospam@xxxxxxxxxx (Paul)
- Date: Fri, 05 May 2006 17:51:19 GMT
In article <n1fl52t14psdmp409i5qptk35s41ohs8ne@xxxxxxx>,
Increasing Vcore is useful if you are overclocking (as a safety
precaution based on the "Vdimm-Vcore" being the dangerous
parameter.) But since Vcore is not used to interface to the RAM,
it won't change your RAM stability. If you ran Prime95 and used
small FFTs (which has less reliance on memory, and should run
"in cache"), and got errors, that might be a justification for
Hmmmm . . . so many variables. Are you suggesting running Prime95 at
small FFTs AFTER I find timings that allow these DIMMs to run the
computer stably or running Prime95 at something like their spec,
I'm saying Vcore is used to stabilize the CPU core. If you are
not overclocking, the Vcore specified by AMD, should be more than
enough to do the job. For example, I saw a plot provided by AMD,
and they include some margin when they test, so the Vcore should be
more than adequate. The margin has to be present, in order for
CNQ to work without a problem. Obviously, to be able to test for
CPU stability, ya gotta have working RAM :-) If you can come up
with a temporary fix for your RAM problem, you are free to test
for CPU core stability using the Prime95 small FFT torture test,
as that should stay in cache and not access the memory. You can
try dropping Vcore until it crashes, and that would give you some
idea how much margin you have. It would be best to do that with
CNQ disabled, so the voltage stays fixed at the value you select.
I don't know what voltage values get used when CNQ is enabled,
and it might not pay attention to the original BIOS voltage setting.
So many fault cases should lead to a crash, that you have to
postulate some kind of wearout mechanism to get your symptoms.
I mean, I've had bad RAM, but I had stuck-at faults at fixed
repeatable locations in memory. If you experience random failure
locations, that is either a device degradation problem, or
some part of the interface (signal drivers) is failing. And
drivers rely on Vdimm for their supply voltage.
This last paragraph is a little over my head.
My last paragraph is poorly worded. What your symptoms suggest
to me, is there is a wearout effect of some sort going on. It
could be the RAM is just bad (but two separate samples of RAM,
using chips from different batches, shouldn't be doing exactly
the same thing). It could be the RAM is being tortured some
how (too much Vdimm from Asus motherboard ?). Since installing
new sticks fixes the problem, it appears the processor is not
damaged in the process. Since adjusting the timings a bit seems
to fix it (and you should use memtest86+ and Prime95 to prove
that those corrections really fix it), that suggests to me that
something is wearing out.
Another example, it is possible for an Athlon64 processor to
wear out. I've read a number of accounts, from overclocking
freaks, where they note they can run some of their processors
for a number of months, at a given overclock, until one day
that start getting flakyness. They turn down the clock and
carry on. Eventually, the processor will no longer run stable
even at stock settings, at which point the processor goes onto
Ebay :-( Those symptoms could be electromigration, but who
knows for sure.
- Prev by Date: Re: Isn't Command Rate a "memory setting?"
- Next by Date: Re: Isn't Command Rate a "memory setting?"
- Previous by thread: Re: Isn't Command Rate a "memory setting?"
- Next by thread: Re: Isn't Command Rate a "memory setting?"