RAM error under Othos stress test

[s1d3way]

i get this error almost instantly after begin running Othos ram stress test:

========================================================
Type: Large, in-place FFTs - stress some RAM Min: 128 Max: 1024 InPlace: Yes Mem: 8 Time: 15
11/30/2007 1:37 AM
Launching 2 threads...
1:Using CPU #0
2:Using CPU #1
1:Beginning a continuous self-test to check your computer.
1ress Stop to end this test.
2:Beginning a continuous self-test to check your computer.
2ress Stop to end this test.
1:Test 1, 4000 Lucas-Lehmer iterations of M19922945 using 1024K FFT length.
2:Test 1, 4000 Lucas-Lehmer iterations of M19922945 using 1024K FFT length.
2:FATAL ERROR: Rounding was 0.4939193925, expected less than 0.4
2:Hardware failure detected, consult stress.txt file.
2:Torture Test ran 0 minutes 2 seconds - 1 errors, 0 warnings.
2:Execution halted.

1:Torture Test ran 0 minutes 2 seconds - 0 errors, 0 warnings.
1:Execution halted.
========================================================



im using 2GB of Corsair Dominator 800mhz, OC'd to 900 for a 1:1 ratio with a 3.6ghz E6750 (450:450), timing is set at 5-5-5-20 2T, mobo is a P35-DS3L.

what exactly does this error mean?

thanks guys!

 

[Billb2]

Originally posted by: s1d3way
i get this error almost instantly after begin running Othos ram stress test:
...2:FATAL ERROR: Rounding was 0.4939193925, expected less than 0.4

1.) the memory is faulty
2.) Your timings won't work at that speed
3.) You're overclocking it too much
4.)You're not feeding it enough volts

And, I'd assume that, if you had used a systematic approach to overlocking you'd know what went wrong.
Read some overlocking guides.

 

[BonzaiDuck]

I've been surveying some guides and forums with OC'ing guides, and am quoting as paraphrase below:

"DDR2 latencies are not as important now as were DDR latencies a couple years ago."

I think this is incorrect.

I know -- with a C2D like the E6750 -- I could come close to the OP's settings. But I have a Q6600 B3, so I think I top out somewhere around 3.2 Ghz for keeping my vCore under 1.42V. Unless I drop the multiplier a notch, I can't get beyond a CPU_FSB of 360 Mhz.

But I purchased high-performance RAMs with D9 parts so that I would be able to under-clock them with really tight latencies.

I was fine-tuning this last night, and tightened up tRCD from 4 to 3, and the "advanced" "bank-cycle-time" tRC from 21 to 15. I was stunned by the noticeable improvement in bandwidth.

Regardless of what you hear people say, reducing memory operation clock cycles mathematically guarantees performance improvements that should be easily calculated against increased frequency for comparison.

But I've also found that these two adjustments I spoke of -- already starting with basic tCL, tRCD, tRP and tRAS of 3,4,4,8 with 1T command rate -- will require either a couple megahertz decrease in FSB/DDR speeds, or a tad increase in VDIMM. I'm lucky that I'm only at 2.150V on my VDIMM voltage, and there's still some wiggle-room.

And I'm wondering . . . . if Megahertz . . . . isn't a geek-equivalent to a size or dimension used to promote Viagra . . . .

 

[nefariouscaine]

Originally posted by: BonzaiDuck
I've been surveying some guides and forums with OC'ing guides, and am quoting as paraphrase below:

"DDR2 latencies are not as important now as were DDR latencies a couple years ago."

I think this is incorrect.

I know -- with a C2D like the E6750 -- I could come close to the OP's settings. But I have a Q6600 B3, so I think I top out somewhere around 3.2 Ghz for keeping my vCore under 1.42V. Unless I drop the multiplier a notch, I can't get beyond a CPU_FSB of 360 Mhz.

But I purchased high-performance RAMs with D9 parts so that I would be able to under-clock them with really tight latencies.

I was fine-tuning this last night, and tightened up tRCD from 4 to 3, and the "advanced" "bank-cycle-time" tRC from 21 to 15. I was stunned by the noticeable improvement in bandwidth.

Regardless of what you hear people say, reducing memory operation clock cycles mathematically guarantees performance improvements that should be easily calculated against increased frequency for comparison.

But I've also found that these two adjustments I spoke of -- already starting with basic tCL, tRCD, tRP and tRAS of 3,4,4,8 with 1T command rate -- will require either a couple megahertz decrease in FSB/DDR speeds, or a tad increase in VDIMM. I'm lucky that I'm only at 2.150V on my VDIMM voltage, and there's still some wiggle-room.

And I'm wondering . . . . if Megahertz . . . . isn't a geek-equivalent to a size or dimension used to promote Viagra . . . .

OP - did you think to test your memory settings with Memtest, before going into your OS to try Orthos? Also as above check your voltage on the vDIMM
-------------------------------------------------------
I have to also voice in on this one - I partially agree with BonziaDuck. I think the statement "DDR2 latencies are not as important now as were DDR latencies a couple years ago." could have been based on old 939 vs 775 (pre C2D) - When AMD had the upper hand Clock for Clock over Intel and latencies made huge differences - tides have turned with the Clock/Clock race but IMO AMD still kills Intel with memory bandwidth due to the on-die mem controller.

I did my share of bandwidth and benchmark testing with my C2D to see what I gained from memory Mhz and/or timings

I tried CAS3 at 667 / CAS3 at 800 / CAS4 at 800 / CAS4 at 900 / CAS5 at 1000 / CAS5 at 1066 & 1150

And asides from bandwidth benching I didn't see too much of a difference in real world applications - but like the OP I'm on a dual core, so maybe quad core can use that extra bandwidth better - *but* increases to both CPU speed and adjusting the RAM did show a higher increase than CPU speed alone

 

[BonzaiDuck]

Like the wine-cooler bro's say -- "Thanks fur yur support."

This has really mystified me. The memory-makers, having seen a market for high-performance memory with DDR, may have surged ahead of the board and CPU makers, and now we have boards that will automatically pick an alternative divider to run RAM at a different speed.

But looking back on my experiences with OC'ing, the easiest part is fiddling with the voltages and FSB settings, and tweaking latencies seemed tedious. Now -- I feel very comfortable with it.

And it's interesting -- they've partially shattered the myth that CAS is all-important: tRCD may be even more so. Several settings have only modest impact on bandwidth, but other settings, dependent on those, DO have a stunning impact on bandwidth. This is a sort of paradox.

Here are two examples.

tRAS -- on most of the good modules, defaults to something between 10 and 15. You can tweak it down to 8, but it must always be greater than or equal to the sum of tCL + tRCD. Yet in comparison to those latencies, it has a modest impact on bandwidth.

Then you look at tRP. Again -- a modest impact on bandwidth. But the bank-cycle-time -- tRC (an "advanced" timing) -- must be greater than (or equal?) sum of tRP + tRAS. And tRC has an enormous impact -- at least a "significant" impact -- on bandwidth.

I remember stumbling around in the dark trying to set these latencies, and going through all sorts of upsets in trial-and-error. Now -- if I find an opportunity to knock a clock-cycle off a latency setting -- I may get an error running PRIME95 and have to stop it, and I can drop the FSB/DDR speeds a few Mhz or raise the voltage a tad. But no more cataclysmic panics over freezes, lockups, and the need to "CLR_CMOS."

Now if I could just get "Blend Test" to continue beyond 5 hours without an error, I can probably knock another clock-cycle off tRAS and be done with all this. The light is at the end of the tunnel. Or -- I could almost say -- like Peter Falk "casing" the armoured-car headquarters in the movie "The Brinks Job" --- "I OWN this place!"

But all I'm stealing here is a few clock-cycles. (I can't even sell 'em! )

 

[nefariouscaine]

Originally posted by: BonzaiDuck
Like the wine-cooler bro's say -- "Thanks fur yur support."

This has really mystified me. The memory-makers, having seen a market for high-performance memory with DDR, may have surged ahead of the board and CPU makers, and now we have boards that will automatically pick an alternative divider to run RAM at a different speed.

But looking back on my experiences with OC'ing, the easiest part is fiddling with the voltages and FSB settings, and tweaking latencies seemed tedious. Now -- I feel very comfortable with it.

And it's interesting -- they've partially shattered the myth that CAS is all-important: tRCD may be even more so. Several settings have only modest impact on bandwidth, but other settings, dependent on those, DO have a stunning impact on bandwidth. This is a sort of paradox.

Here are two examples.

tRAS -- on most of the good modules, defaults to something between 10 and 15. You can tweak it down to 8, but it must always be greater than or equal to the sum of tCL + tRCD. Yet in comparison to those latencies, it has a modest impact on bandwidth.

Then you look at tRP. Again -- a modest impact on bandwidth. But the bank-cycle-time -- tRC (an "advanced" timing) -- must be greater than (or equal?) sum of tRP + tRAS. And tRC has an enormous impact -- at least a "significant" impact -- on bandwidth.

I remember stumbling around in the dark trying to set these latencies, and going through all sorts of upsets in trial-and-error. Now -- if I find an opportunity to knock a clock-cycle off a latency setting -- I may get an error running PRIME95 and have to stop it, and I can drop the FSB/DDR speeds a few Mhz or raise the voltage a tad. But no more cataclysmic panics over freezes, lockups, and the need to "CLR_CMOS."

Now if I could just get "Blend Test" to continue beyond 5 hours without an error, I can probably knock another clock-cycle off tRAS and be done with all this. The light is at the end of the tunnel. Or -- I could almost say -- like Peter Falk "casing" the armoured-car headquarters in the movie "The Brinks Job" --- "I OWN this place!"

But all I'm stealing here is a few clock-cycles. (I can't even sell 'em! )

I will check out changing the tRC (after seeing what its at) but I'm at 3-3-3-12 T1 /

per CPU-z I'm at tRC 19 (auto bios settings for advanced...)

I'm running 1:1 at 667 ATM with 2.08v -- Haven't tested that voltage with a DMM but IIRC this board ups the vDim a little bit so I'm prolly closer to 2.13v

I have 3 kits of D9's I like to play with and need to RMA another 1 too - for some reason they just don't like 2.4v when i'm trying to get CAS3 at DDR2-900

 

[BonzaiDuck]

Although some of the guides I've read on AMD OC'ing suggest leaving the Mem voltage for last, and I always used to start with the midpoint of the range, I'm making fine adjustments to the highest OC I can get with Q6600 B3 and vCore just below 1.42V. So tightening down the latencies a bit more, I ran up the vDIMM by 0.025V to 2.175, and this has the BIOS monitor reporting 2.22V.

Voltage aside, you might want to see what happens to the Crucials if you drop the tRC from 19 to 16 or 17. According to my sources, tRC has minimal impact on stability, but much influence on bandwidth.

If you can come down with the tRAS from 12 to anywhere from 11 to 6, then you can lower tRC clock-cycle for clock-cycle. tRAS also has minimal impact on stability, as long as you play by the rules with it.

The "Auto" setting on these ASUS mobos reads the SPD or EPP values, and probably assumes that you're using the latencies that are stored there. That's probably why it's so high. My "Auto" value was 21, and that timing can go as high as 30.

The ironic thing here is this: I suspect that your DDR2-667 Crucials with tCL=3 will run the same latencies that my DDR2-1000's will run at that speed. And the only value I get out of having the more expensive modules is the ability to run them at those speeds on a divider. But the only way I can do that is to loosen the timings again. So it's an option that I paid for -- a tangible "quality feature" -- but I'm not all that goo-gah about using it.

The other thing -- I was reticent -- timid -- about pushing the memory voltage higher than 2.15, when there were two notches-worth to spare. For this, I thought I couldn't run these modules near 700 Mhz at 3,3,3,6 timings. In fact, I thought I HAD to run them at 3,4,4,8. But they seem rock-solid now at 700 as 3,3,3,7, and I know that there is some way -- maybe even an easy way of just lowering tRAS -- and I can probably run them at 3,3,3,6. Then I can run the tRC at 10.

But if you try to take those modules as high as 900 Mhz, you would have to loosen the timings. I hope you can get the RMA replacement, but 2.4V is pushing your luck, I think, and also, for my own ASUS nForce (680i) board, the gurus at the ASUS forums say that the "board will kill your RAM if you set the voltage too high" and that the board "doesn't like voltage too high" for RAM.

But like me, you seem to have ample extras . . . .

Also -- word of caution -- I think tRC needs to be one clock-cycle (or more) greater than tRP + tRAS. I haven't tried making it "equal to," but the wording of what I've read suggests only ">".

 

[nefariouscaine]

I dropped the tRC down to 15 (tRC= tTP + tRAS) and haven't noticed any stability issues and I'm just getting ready to check out bandwidth testing - I don't think the Asus board was getting the 19 tRC from an SPD or EPP setting as the lowest any of those went was 20 but I could be wrong...I think it tightens up if not running at SPD speeds

I actually need to change my sig as I'm running a new set of 800mhz Crucials and have a unopened brand new tasty set of 667's (not Anniversary - said I got the last module the time before...) and need to RMA the other set of Anniversary Series I have. I also got access to a set of Micron D9 ECC sticks that I was running at DDR2-900 at 4-4-4-4 T2 Auto advanced settings on 2.4v and those have never failed me yet - didn't do the whole range of testing on them but they did 1000mhz just fine with 2.178v at CAS5.

I'm gonna replace them out of my friends computer with some value ram so I have more to play with

I'll see what I can play with the timings for now but I'd like to stick to voltage being lower than allowed at this point. I know D9 GMH can do amazing things (that 667 ran fine at 1200 for a while...) but as you said its known Nvidia boards kill memory

 

[BonzaiDuck]

Did you ever notice the erroneous bandwidth posting with nForce boards and Memtest86?

I read somewhere today, possibly some "over-clocking guide" in a forum, that "680i did not 'play nice' with MEMTEST86." But I think the assessment of an ASUS guru per their 680i boards was different.

What I DO see is the bandwidth estimate going DOWN as I punch up the DDR and FSB with the same latency setting.

IF you're CORRECT that there are no stability issues with tRC = tRP + tRAS as opposed to tRC - 1 = tRP + tRAS, that could be really good news.

I've found significant gains in the bandwidth benchmarks for each clock-cycle decrease in tRC.

The reason I say 680i mobo may calculate default tRC from SPD/EPP is that my "Auto" setting is 21, and the default SPD ( or EPP?) timings for this Cru'l Ball'x DDR2-1000 are 5,5,5,15.

I finally punched up my VDIMM to 2.2V with monitored value at 2.24V. Then I added another 0.05V to CPU_VTT(FSB) voltage -- set to 1.45V, but reading 1.52V. Now I think that my VCORE had been set higher than necessary at 4.125V, because I just went up in DDR from 712 to 720 at that VCORE, and it seems stable so far. And THIS -- with the latencies at 3,3,3,6,2T and tRC at 10!! If you're right, I can knock off another clock cycle.

The Everest benchies are now something like 9,520 MB/s "read," around 6,500+ MB/s each for "copy" and "write," and the latency is something like 52ns.

If this just goes an hour or two stable with no errors, I'll be tempted to terminate it and just see what TrackMania United "Island->Difficult->Track D1" is like.

. . .. and it was really flyin' down the road this morning -- gotta tell ya . . . a real heart-stopper . . . .

* * *

So . . . . for "her209's" post in the other thread -- "No -- you don't need to run DDR2-800's at DDR2-667, but you don't need to run them at 800, either . . . . "

* * *

"God said, "Let there be SILLY-CONE!!" And the beaches were filled with it, and it was good.

And the Founding Fathers said "Let companies like Micron prosper!" And they did.

And the Great Lord Micron begat D9 chips, and the Geeks of the Earth saw that it was good, too. And they ran up their VDIMM to 2.2V, and discovered high FSB and low latencies. And after days and nights of PRIME95 testing, they took a day of rest . . .

. . . . and gave thanks for the manna of Bandwidth.