HCI Memtest "behaviors"

[BonzaiDuck]

I'm going to post this here versus using the Memory and Storage forum, because the subject is stress-testing software specifically directed at memory-over-clocking.

On at least two occasions when running the CD-bootable version of the latest HCI Memtest revision, the machine simply re-booted -- which I assume meant that the program had encountered a failure.

The info on the program's DOS-text screen notes that "all failures will be reported." But I've not seen any reports: I've only seen the test go longer and longer without failure and reboot after bumping up the requisite voltage(s) a notch.

The same thing happened when I ran the multiple instances of HCI Memtest in Windows. It apparently had reached 150% coverage, and I discovered the machine asking for my password the next morning. Event Logs indicated approximately when and how the failure or reboot had occurred. But I saw no "errors reported."

Is this standard behavior for this program?

 

[Idontcare]

HCI Memtest itself has never rebooted my machine, but I've only used the windows version. When HCI has encountered errors in my ram it has simply stopped the specific instance of HCI and reported that an error was encountered.

If running HCI is causing your rig to spontaneously/autonomously reboot then that sounds like HCI is highlighting an instability in your computer that might be more devilish than a mere memory chip problem.

 

[BonzaiDuck]

HCI Memtest itself has never rebooted my machine, but I've only used the windows version. When HCI has encountered errors in my ram it has simply stopped the specific instance of HCI and reported that an error was encountered.

If running HCI is causing your rig to spontaneously/autonomously reboot then that sounds like HCI is highlighting an instability in your computer that might be more devilish than a mere memory chip problem.

It could be "something else," but I'm going to find out -- maybe by tomorrow. This is the same kind of thing I brought up last year in that old "Prime95 . . . BSOD . . ." thread, where we all shared data. I think I'd just verified that I wasn't getting BSODs anymore. And I thought I should instead have got a "red stop" icon on a thread window of the Prime95 -- but that's why I posted the thread.

Since then, this system has been rock-solid. That's until I added the second memory-kit and first tried running them at 266Mhz over the spec 1600. It looks to me (so far) that bumping up the VCCIO to just a twinkle over the spec 1.10V will do the trick per this "instability." I guess I'm going to find out . . . I'm running the same DDR3-1866 settings you mentioned . . . 10-10-10-28 -- at a 1T command-rate.

[I thought I'd asked you what VCCIO you were running on the MIVE board with the two kits of -GBRL G.SKILL 1600s @1866 . . I think the phase-power-design and other features are essentially the same between the MIVE and the 'Z68-VPro. ]

 

[Idontcare]

[I thought I'd asked you what VCCIO you were running on the MIVE board with the two kits of -GBRL G.SKILL 1600s @1866 . . I think the phase-power-design and other features are essentially the same between the MIVE and the 'Z68-VPro. ]

doh! my bad if I dropped the ball there. Let me check...

When I am using my 2600k the the VCCIO is 1.058V (sometimes it becomes 1.065V for no apparant reason, must just be the natural range of fluctation).

I'm pretty sure the same number is there when I have my 3770k installed but I don't have a screencap to confirm. I will try and remember to grab one next time I boot the IB setup.

 

[BonzaiDuck]

doh! my bad if I dropped the ball there. Let me check...

When I am using my 2600k the the VCCIO is 1.058V (sometimes it becomes 1.065V for no apparant reason, must just be the natural range of fluctation).

I'm pretty sure the same number is there when I have my 3770k installed but I don't have a screencap to confirm. I will try and remember to grab one next time I boot the IB setup.

Well, I'm not so "far gone" at this age to know or realize that my posts in threads can be prolix, and some PM's may have been no less so.

Generally, the instructions and "diagnostics guides" for these softwares like Memtest, etc. are sparse. One is left to his or her own common sense to deduce "why stuff happens the way it does." It should dawn on someone [like me] that the program is designed to test memory errors, as opposed to some voltage problem that might affect stability -- memory-related or otherwise.

Some advice suggests simply setting VCCIO to 0.05V above spec (1.1V) before any systematic over-clocking, but I see we both may have taken the incremental approach. I'm currently above 1.11V, and I'm more hopeful now, since I've passed the coverage percentage elapsed before the sudden re-boot last time I tried to suffer through this memory test.

If there's really nothing wrong with my RAM, then you apparently have the stronger system, better G.SKILL sticks or better settings, since I was only reducing instability as I passed adjustment to the voltage you cite as your own.

RE-TAKE: Oh-HO! I see you bumped up your VCCSA a tad! I'll have to update my BIOS to the next version after 606 just to have that luxury!

 

[Idontcare]

RE-TAKE: Oh-HO! I see you bumped up your VCCSA a tad! I'll have to update my BIOS to the next version after 606 just to have that luxury!

I did? I don't remember doing that, pretty sure I have it set to auto in the BIOS...but I did update the BIOS, it was about 4 revs out of date when I updated it to the most recent BIOS, so maybe ASUS increased the default auto value?

I may just have intrinsicly better ram or intrinsicly cleaner signal:noise on my mobo that enables the ram to operate as it does. That said, I have never been able to get the ram to be HCI-stable at its rated speed and latency for DDR3-2133, I even RMA'ed all four sticks to address that and the new ones aren't HCI-stable either.

 

[BonzaiDuck]

I did? I don't remember doing that, pretty sure I have it set to auto in the BIOS...but I did update the BIOS, it was about 4 revs out of date when I updated it to the most recent BIOS, so maybe ASUS increased the default auto value?

I may just have intrinsicly better ram or intrinsicly cleaner signal:noise on my mobo that enables the ram to operate as it does. That said, I have never been able to get the ram to be HCI-stable at its rated speed and latency for DDR3-2133, I even RMA'ed all four sticks to address that and the new ones aren't HCI-stable either.

I thought the VccSA was supposed to default to a value somewhere around 0.95, 0.953, something like that. Maybe your BIOS upgrade did add to it on Auto, but an awful lot of people were consistent in the default value I cite here.

There seems to be a school of thought which says the SB and (probably) IB IMCs are strong enough to handle RAM speeds up to 2133 (or higher?). So the wisdom is "don't bother it." The other school suggests tweaking VccSA by a couple millivolts here or there, alternately to VCCIO and RAM voltage.

On the -GBRL or (possibly) -GBXL 1600's, one tech-rep at the G.SKILL forum suggested twisting up the RAM voltage to 1.65, at which point you were supposed to able to run the sticks at 2133 and 9-10-9-something.

Now that I think of it, there had been a review of the -GBRL kit in which the reviewer had simply knocked up the voltage to 1.65 and tested latencies of 7-7-7 @ 1600, 9-9-9 or 8-8-8 at 1866, and couldn't seem to get them to run stable beyond about 2000Mhz [more like 1980 and change.]

I like keeping the RAM or vDIMM around 1.5 +/- 5%, and living with the result. this is a GOOD result. Those kits had been available since at least the release of P67 motherboards, and they may not be the best bang-for-the-buck compared with these Samsung 30nm kits we've been talking about, but they're still cheap and quite reliable. Anyway, the skinny on the street says G.SKILL uses Samsung "black parts."

 

[Idontcare]

Yeah my VCCSA is set to "auto" in the BIOS. But the auto value fluctuates between 1.058 and 1.065 for no apparent reason as far as I can tell.

However, I too ended up talking about VCCIO/SA with the Gskill tech support rep before being issued my RMA and he didn't even ask me what my VCCIO value was, he just cut right to the chase and told me to set it to 1.075V and retest the ram to see if that made the instability go away.

(it didn't make it go away, so he issued me an RMA)

If the default value of 1.058V is too high then all I can say is that I am not surprised. This motherboard irritates me because of how ASUS set it up.

For instance even though the ram is stock 1.5V, its in the SPD and all, the BIOS defaults the ram to 1.65V whenever the CMOS gets cleared. I have to be johnny-on-the-spot to get into the BIOS and manually set that voltage down to 1.5V before I tear up my IMC.

But why does ASUS make a BIOS that defaults the ram to a value that is truly out of spec for any and every CPU that will ever be plugged into the socket? (not too mention that technically ASUS forced me to invalidate my CPU warranty since my CPU had then experienced a Vdimm >1.57V)

Another example is my 2600k Vcc. At stock with a cleared bios, the mobo boots up and defaults the Vcc to an astounding 1.45V D:

I'd expect crappy stuff like this from a budget-end mobo which of course has had questionable resources allocated to the BIOS dev team. But this is a $350 mobo, it costs more than the CPU, and yet it can't get the stock/default/auto voltages right?

Lame. :\

So I'm not surprised at all if my VCCIO is out of spec despite being set to auto. That's just how they roll over at the ROG.

 

[BonzaiDuck]

Yeah my VCCSA is set to "auto" in the BIOS. But the auto value fluctuates between 1.058 and 1.065 for no apparent reason as far as I can tell.

However, I too ended up talking about VCCIO/SA with the Gskill tech support rep before being issued my RMA and he didn't even ask me what my VCCIO value was, he just cut right to the chase and told me to set it to 1.075V and retest the ram to see if that made the instability go away.

(it didn't make it go away, so he issued me an RMA)

If the default value of 1.058V is too high then all I can say is that I am not surprised. This motherboard irritates me because of how ASUS set it up.

For instance even though the ram is stock 1.5V, its in the SPD and all, the BIOS defaults the ram to 1.65V whenever the CMOS gets cleared. I have to be johnny-on-the-spot to get into the BIOS and manually set that voltage down to 1.5V before I tear up my IMC.

But why does ASUS make a BIOS that defaults the ram to a value that is truly out of spec for any and every CPU that will ever be plugged into the socket? (not too mention that technically ASUS forced me to invalidate my CPU warranty since my CPU had then experienced a Vdimm >1.57V)

Another example is my 2600k Vcc. At stock with a cleared bios, the mobo boots up and defaults the Vcc to an astounding 1.45V D:

I'd expect crappy stuff like this from a budget-end mobo which of course has had questionable resources allocated to the BIOS dev team. But this is a $350 mobo, it costs more than the CPU, and yet it can't get the stock/default/auto voltages right?

Lame. :\

So I'm not surprised at all if my VCCIO is out of spec despite being set to auto. That's just how they roll over at the ROG.

Well, when they spec the product, it's so they can guarantee that the RAM will run at a particular speed, voltage and latencies. It doesn't mean they won't run at another set of speed, volts and latencies, but they're essentially guaranteeing that you won't have to tweak anything. This of course is eclipsed by the ASUS default 1.65V feature, which I also noticed right away.

This is at least secondhand from readings I'd made from non-Intel sources, but I thought the SB VCCIO "nominal" spec was 1.10V. I wouldn't know what it is for IB at this moment. I'd bet . . . probably lower. You'd think the SB wisdom would apply -- there should be a safe range above an IB nominal spec.

I'd overvolted the RAM at the beginning last year to about 1.515V, and left it there. That was at stock settings 1600 9-9-9-24 2T. So when I started testing at 1866, I thoughtlessly bumped it up to around 1.525. Then realized that the VCCIO voltage may have almost everything with the VDIMM almost nothing to do with failures/errors/re-boots. So now, I've turned down the VDIMM to around 1.515V again, knowing that it might be stable even closer to 1.50. But neither the 0.015V difference nor the length of testing warrants my lowering it, when I'm about to show success to 1000% coverage on these settings. The VCCIO is still running below 1.115, and it could be increased all the way to 1.15 without worry or care.

 

[BonzaiDuck]

I thought I would "report" on the seemingly useless exercise of over-clocking my DDR3-1600 Ripjaws "-GBRL" 4x4GB RAM.

I'd set the RAM voltage about 20-millivolts over the spec 1.5V since last summer. I might have dropped it back to 1.50V for stress-testing the RAM at DDR3-1866 10-10-10-28 1T, but chose to leave it. Can't see the harm, really -- 1.52V, +/- 0.01V.

I had goosed up the VCCIO from 1.076+V to 1.112V. The test ran through 1,100% coverage with zero errors over some 60 hours.

I keep wondering about what I "perceived" as this test was running. It often looked as though some 100% sequences took longer to complete than others. So one wonders what this test is doing, or how it is doing it.

Now -- this may or may not be related to the OC'd RAM settings. Media-Center HDTV, about 20 web-pages, e-mail, my Paperport document manager, Quicken, etc. -- all running concurrently. I brought up the AIDA-64 memory-and-cache benchmark program . . . 40.5ns memory latency . .. fine. Come back an hour later, and the AI Suite II monitoring software reports a warning that the motherboard temperature is MINUS 60C degrees.

Rebooted -- BIOS monitor shows 30C motherboard and 29C for the processor. Fine. AI Suite II "monitor" -- 30C motherboard and fine.

I'm trying to figure out whether this is some random glitch, some "timing" error that was random or specific to certain combinations of programs or actions I'd taken, some stray cosmic ray . . . . whatever. Last thing I'd want, of course, is to find that the RAM is "misbehaving" after the over-clock. I just don't see how that would be possible, since HCI Memtest64 bootable-CD "DOS" version ran for 60 hours and 11 iterations without fail.

I welcome any insights.

 

[Idontcare]

BTW I did go back and confirm the VCCIO with IB installed and it is the same as when SB is in the socket: 1.058 - 1.065

As for the concerns you have regarding your other observations, I have no insights or ideas. In my experience when boards give off spuriously bad readouts it is because something in the overall platform is being pushed to the ragged edge of stability.

I notice this with the ASUS AI Suite using TurboV EVO, while running LinX if I get the Vcc set just right on that hairiest of hairy edges where LinX is not crashing and windows is not BSOD'ing but I get random programs bombing out in the background - and AI Suite will start throwing up the weird alarm pop-ups "GPU voltage is 0.005V!" and "USB port xyz has experienced a power surge!".

Every time that has happened for me, a single bump up on the Vcc dial makes all the weirdness go away. It might not be a universal enough of a symptom/disease situation to be relevant to your situation, but I thought I'd share it in case it was.

 

[BonzaiDuck]

BTW I did go back and confirm the VCCIO with IB installed and it is the same as when SB is in the socket: 1.058 - 1.065

As for the concerns you have regarding your other observations, I have no insights or ideas. In my experience when boards give off spuriously bad readouts it is because something in the overall platform is being pushed to the ragged edge of stability.

I notice this with the ASUS AI Suite using TurboV EVO, while running LinX if I get the Vcc set just right on that hairiest of hairy edges where LinX is not crashing and windows is not BSOD'ing but I get random programs bombing out in the background - and AI Suite will start throwing up the weird alarm pop-ups "GPU voltage is 0.005V!" and "USB port xyz has experienced a power surge!".

Every time that has happened for me, a single bump up on the Vcc dial makes all the weirdness go away. It might not be a universal enough of a symptom/disease situation to be relevant to your situation, but I thought I'd share it in case it was.

I appreciate that. In fact, the other night I was "LinX-ing" with the AI Suite monitor running in background. Point is, I'd started up the ASUS monitor AFTER starting LinX. That's always been a formula for the classic Windows "Program not responding."

Frankly, I think my Vcc or VCORE is a tad too high, so next week I'm going to tweak. Maybe the problem arose because I ran the memory benchmark with all that other stuff in the background -- don't rightly know. I've got my eye on it . . .

But there's plenty of "headroom" to tweak the RAM some more (shouldn't need it), and I can adjust the other voltage settings. "Time for a shake-down cruise!"

 

[Idontcare]

I appreciate that. In fact, the other night I was "LinX-ing" with the AI Suite monitor running in background. Point is, I'd started up the ASUS monitor AFTER starting LinX. That's always been a formula for the classic Windows "Program not responding."

Frankly, I think my Vcc or VCORE is a tad too high, so next week I'm going to tweak. Maybe the problem arose because I ran the memory benchmark with all that other stuff in the background -- don't rightly know. I've got my eye on it . . .

But there's plenty of "headroom" to tweak the RAM some more (shouldn't need it), and I can adjust the other voltage settings. "Time for a shake-down cruise!"

I have to use task manager and set the task priority for Asus AI Suite to "High" (just one notch below real-time) if I don't want it to freak out and become unresponsive when running LinX. And that is with LinX only running 4 threads, leaving plenty of HT cycle for a background program like AI Suite.

I'm sure it has something to do with interrupt polling or some such, given all the hardware registers the program is attempting to access when polling.

 

[BonzaiDuck]

I have to use task manager and set the task priority for Asus AI Suite to "High" (just one notch below real-time) if I don't want it to freak out and become unresponsive when running LinX. And that is with LinX only running 4 threads, leaving plenty of HT cycle for a background program like AI Suite.

I'm sure it has something to do with interrupt polling or some such, given all the hardware registers the program is attempting to access when polling.

Also, my own instincts about another phenomenon were supported by some brief exchanges I had here at the forums a few years back. I think it is possible that running two monitoring programs is a bad idea, if they're both accessing sensors at the same time. AI Suite II was running in background, and I'd pulled up AIDA-64 -- possibly opened the sensor page before I ran that memory benchmark.

I finally did a good reading of your posts on setting affinity to cores while HT is enabled for running LinX. Seems like a lot of extra trouble, but I'm going to approach it that way. At least Prime95 doesn't require fiddling with the checkboxes. Or -- at least I use Prime as well as LinX or IBT for proving stable settings.