Official Haswell-E thread

[BonzaiDuck]

As I was told on several occasions, high temperatures are supposed to have a deleterious effect of increasing electrical noise in motherboard and [likely] CPU circuits.

At the same time, IDontCare had posted results showing that reductions in temperature did not make a given overclock profile stable at significantly lower voltages.

Extra cooling will only buy you a better chance of stability if it reduces the electrical noise occurring during peak operation. You would still be required to operate at the same voltage, which is a primary determinant of the heat you're trying to get rid of.

I only come by these things -- if they are correct -- because folks in IDC's trade know a lot more than I do about the electronics, the thermal properties of silicon and other materials. But I have a decent grasp of the statistics, distributions, measures like "standard error."

So . . . pay attention to IDC . . .

 

[Dave3000]

Yes, in addition to the hardware failure rate, there is a software failure rate as well.

This is why people advise to "undo your overclock and see what happens when running stock" when someone is asking for help because of their rig being unstable. The idea being that at stock the likelihood of a hardware-induced error (while still being non-zero) is vastly less than the likelihood of a software-induced error (which would continue to remain present regardless of the hardware parameters).

But you nailed it with your one-line summary:


Bingo. And if you are trying to compare your OC to another person's OC then you need some way of making it apples-to-apples and that is why having an agreed upon "working definition" of stability is required even for OC'ing enthusiasts.

One person's 4.8GHz OC (that crashes every 2 weeks) is not comparable to another person's 4.5GHz OC (that crashes every 2 months), to make their OC'ing "achievements" comparable they need to demonstrate equivalent stability with a pre-defined (albeit still arbitrarily so) torture test the likes of LinX or Prime95, specific memory settings (determines matrix size), and specific time or number of passes.

What if it's some random infrequent issue in a game (like kicked out to the desktop or a system freeze, or just a game acting weirdly) that you have a hard time reproducing the error again a stock settings and you overclock again to see if it really was the overclock causing the error but you still can't get the issue to happen again? Is it best just to assume overclocking caused the issue if you are not sure if it was caused by a software issue or an unstable overclock you should stop overclocking?

 

[BonzaiDuck]

What if it's some random infrequent issue in a game (like kicked out to the desktop or a system freeze, or just a game acting weirdly) that you have a hard time reproducing the error again a stock settings and you overclock again to see if it really was the overclock causing the error but you still can't get the issue to happen again? Is it best just to assume overclocking caused the issue if you are not sure if it was caused by a software issue or an unstable overclock you should stop overclocking?

I think sloppy code might be an elusive sort of problem.

I recently found a forum post at a software-house web-site. There were glitches in the software mentioned in forums where someone came back six months and then a year or two later to get confirmation from the others that the problem had not been fixed.

On the same forum, some guy asserting that changing RAM to XMP profile eliminated chances of freeze or instability working with the company's flagship software program.

Another case, for the same software, which had been touted years ago for allowing two client-workstations to access files on a network if two seats or PCs are purchased in the licensing.

Years later, a note in forums and indications in the software promotional material -- "only 'Pro' version . . for network access . . " It indicated the same sort of freezes, BSODs and lockups as with the other causes.

Overclocking only makes the problem dilemma more complicated. If the same error happens with the same regularity no matter how occasional, you can set everything back to stock settings. If it continues to happen just as frequently, you are sure to have eliminated the overclocking as the cause.

A person could go to a lot of trouble trying to isolate a software-related problem on a software-rich computer.

 

[Idontcare]

What if it's some random infrequent issue in a game (like kicked out to the desktop or a system freeze, or just a game acting weirdly) that you have a hard time reproducing the error again a stock settings and you overclock again to see if it really was the overclock causing the error but you still can't get the issue to happen again? Is it best just to assume overclocking caused the issue if you are not sure if it was caused by a software issue or an unstable overclock you should stop overclocking?

In that specific set of circumstances, with an error that is seemingly random and not reproducible (not systematic), you have to undertake an even more rigorous troubleshooting protocol to isolate and identify the culprit.

Further, a double whammy can be created in those cases for which the enthusiast has OC'ed the bejesus out of their system to the point that the hardware is not only unstable at OC'ed settings, but has deteriorated and become so badly degraded that it will still yield hardware errors at stock settings.

Under those circumstances, the end user can easily be led to be believe (falsely) that the root cause problem is a software error. Such "false positives" are the bane of any engineer's root-cause investigative efforts, or the bane of any technical support rep who is attempting to deal with an otherwise irate and frustrated customer via phone/chat/email/etc.

I've been on both sides of that fence, felt really really dumb when I finally realized the crux of my problems was that I had inadvertently fried my CPU (long story) but was convinced it was an ASUS mobo problem. I still buy ASUS mobo's to this day, partly because I like the features on the ROG series, but also partially out of penance to attempt to help them recover their lost investment in technical support on me :\

 

[BonzaiDuck]

In that specific set of circumstances, with an error that is seemingly random and not reproducible (not systematic), you have to undertake an even more rigorous troubleshooting protocol to isolate and identify the culprit.

Further, a double whammy can be created in those cases for which the enthusiast has OC'ed the bejesus out of their system to the point that the hardware is not only unstable at OC'ed settings, but has deteriorated and become so badly degraded that it will still yield hardware errors at stock settings.

Under those circumstances, the end user can easily be led to be believe (falsely) that the root cause problem is a software error. Such "false positives" are the bane of any engineer's root-cause investigative efforts, or the bane of any technical support rep who is attempting to deal with an otherwise irate and frustrated customer via phone/chat/email/etc.

I've been on both sides of that fence, felt really really dumb when I finally realized the crux of my problems was that I had inadvertently fried my CPU (long story) but was convinced it was an ASUS mobo problem. I still buy ASUS mobo's to this day, partly because I like the features on the ROG series, but also partially out of penance to attempt to help them recover their lost investment in technical support on me :\

You're absolutely correct, but as you also know, there are "Alpha" and "Beta" errors in measurement and sampling. You can miss an assignable cause to a problem or fail to recognize it, and you can also "identify" something as an assignable cause when it "isn't."

In my own case, I went through a litany of concern over some six months last year, trying to resolve an instability so infrequent that it could occur once a week or once a month. I'm quite sure the processor wasn't degraded: it would pass the same stress-tests with the same BIOS settings the way it passed them when I'd only had the system for three months. Setting the processor back to stock did not eliminate the problem; I could set it again to the OC and it would be rock-solid under load.

At this point, I could only identify a handful of "possible" causes which may have been operative in concert. One of those causes may have been over-assignment of limited motherboard resources; another may have been software -- or even software interaction with hardware settings.

Unfortunately, I cannot rightly say which it was. I can only say it wasn't the over-clock settings. The CPU doesn't seem to be "degraded" in any way; I haven't needed to adjust the CPU voltage settings to make it more stable. Review of the event logs shows that the system has been free of "Event ID 41" for at least three months, 24/7 -- non-stop.

Of course, this speaks to the wisdom of "voltage-disciplined" overclocks. I would be fairly confident that nothing bad has happened to the processor. Running the system at stock and variously at the OC settings never turned up any stability problems under severe stress.

 

[Idontcare]

At this point, I could only identify a handful of "possible" causes which may have been operative in concert. One of those causes may have been over-assignment of limited motherboard resources; another may have been software -- or even software interaction with hardware settings.

Oh man, you have my sympathy! Can only imagine what manner of exasperated hair-pulling was involved while trying to troubleshoot and run down that root-cause!

 

[BonzaiDuck]

Oh man, you have my sympathy! Can only imagine what manner of exasperated hair-pulling was involved while trying to troubleshoot and run down that root-cause!

See, to my credit, I had a predetermined annual computer-parts budget. I was intent on making certain upgrades anyway. I went through the whole gamut, cleaning up the errors shown in event logs and tweaking the system for successful backups and other operations. Replaced hardware according to my annual amount, but earlier than planned.

I moved my media hard disk to the Intel controller, and disabled the Marvell controller and the Asmedia USB3. Asmedia is replaced by PCI-E Hoo-Too card. And I'm still suspicious about the reports of a NUANCE software misbehaving when RAM isn't set to an XMP profile. But I followed the advice in a recent Anand article and set it to XMP, anyway.

Whatever it was, it is gone. I got my HW upgrades and solved all my little red-and-yellow events. It was a lot of trouble . . .

 

[exar333]

A little late to the party, but got my build done (finally!!).

Running a pretty rough 4.4ghz OC and it's rock-solid so far. Doing more stress-testing this weekend and hoping to get ~4.6ghz after more tweaking.

As for the ASRock board, it's pretty good. I like my old Asus UEFI bios better, but they don't have a mAtX board...so far pretty impressed.

Link to my build thread below. Will be uploading some more final pics this weekend!

http://forums.anandtech.com/showthread.php?t=2403342

 

[biostud]

A little late to the party, but got my build done (finally!!).

Running a pretty rough 4.4ghz OC and it's rock-solid so far. Doing more stress-testing this weekend and hoping to get ~4.6ghz after more tweaking.

As for the ASRock board, it's pretty good. I like my old Asus UEFI bios better, but they don't have a mAtX board...so far pretty impressed.

Link to my build thread below. Will be uploading some more final pics this weekend!

http://forums.anandtech.com/showthread.php?t=2403342

Yeah, I'm really happy with my Asrock board as well.

 

[Jhatfie]

Just getting started with my 5820k and ASRock X99X. 4.4GHz appears to be solid at 1.35v, but I think that is about it for this cpu as I do not want to go higher with the voltage. Might try a different strap and mess with the bclk to see if that makes any difference. Running my G.Skill at 2666Mhz, working on seeing if I can lower timings next and then I'll mess with the cache, which thus far seems to be really sensitive. Way more so than my 4770k was.

 

[biostud]

Just getting started with my 5820k and ASRock X99X. 4.4GHz appears to be solid at 1.35v, but I think that is about it for this cpu as I do not want to go higher with the voltage. Might try a different strap and mess with the bclk to see if that makes any difference. Running my G.Skill at 2666Mhz, working on seeing if I can lower timings next and then I'll mess with the cache, which thus far seems to be really sensitive. Way more so than my 4770k was.

Mine run stable @ 1.275.

 

[Jhatfie]

Mine run stable @ 1.275.

I think I just did not do very good in the silicon lottery this time around. I wish mine was stable at that voltage. I'll keep messing around though, it may be able to do a bit better.

 

[Lepton87]

A little late to the party, but got my build done (finally!!).

Running a pretty rough 4.4ghz OC and it's rock-solid so far. Doing more stress-testing this weekend and hoping to get ~4.6ghz after more tweaking.

As for the ASRock board, it's pretty good. I like my old Asus UEFI bios better, but they don't have a mAtX board...so far pretty impressed.

Link to my build thread below. Will be uploading some more final pics this weekend!

http://forums.anandtech.com/showthread.php?t=2403342

Have you tried using OCCT as a stress test for at least 60minutes? My system can be stable everywhere by as much as 200MHz higher than in OCCT.

Just getting started with my 5820k and ASRock X99X. 4.4GHz appears to be solid at 1.35v, but I think that is about it for this cpu as I do not want to go higher with the voltage. Might try a different strap and mess with the bclk to see if that makes any difference. Running my G.Skill at 2666Mhz, working on seeing if I can lower timings next and then I'll mess with the cache, which thus far seems to be really sensitive. Way more so than my 4770k was.

Running with 4/3 memory multiplier is not ideal, try running with 1:1 multi, if you are using 100MHz strap that would be either 2600 or 2800 or 2500 or 2750 with 125MHz strap. As for why:
http://pclab.pl/art59968-4.html

Also try that OCCT, I can be stable in LinX for hours and it crashes in OCCT within minutes and if it crashes in OCCT it will crash somewhere else when you least expect it.

 

[exar333]

Have you tried using OCCT as a stress test for at least 60minutes? My system can be stable everywhere by as much as 200MHz higher than in OCCT.



Running with 4/3 memory multiplier is not ideal, try running with 1:1 multi, if you are using 100MHz strap that would be either 2600 or 2800 or 2500 or 2750 with 125MHz strap. As for why:
http://pclab.pl/art59968-4.html

Also try that OCCT, I can be stable in LinX for hours and it crashes in OCCT within minutes and if it crashes in OCCT it will crash somewhere else when you least expect it.

Yeah, just wrapped-up actually. Ran memtest to get 200% coverage at stock 2666mhz speeds and then moved-on to CPU.

Heat is definitely not an issue as the loop keeps the CPU between 50-60C running at 4.5ghz. I was not having a lot of luck using a straight multi to get past 4.4ghz.

Switched to a 1.25 bclk strap and a 36 multi for 4.5ghz. Running uncore at 3500mhz as well. Not sure if this board will support an uncore much higher, will test that after I dial-in the CPU...

Creeping my voltage down from 1.32 to get the lowest, stable voltage my CPU supports and then on to the uncore.

 

[biostud]

So I finally tried OCCT and found out I couldn't get it stable @ 4.4Ghz but had to lower to 4.3Ghz @ 1.3V.

At 4.4Ghz it would BSOD within 30 minutes. I also found out that the different cores behave quite different. Core 2 and 4 are up to 15C hotter than the one running coolest.

So to me OCCT seems like a good stability tester that doesn't create the AVX torture heat.

 

[EvilNodZ]

I found i have 5 good cores and 1 bad core that runs a lot hotter than the others. I think its the 1 bad core that has them binned as 5820Ks.

 

[Arachnotronic]

I found i have 5 good cores and 1 bad core that runs a lot hotter than the others. I think its the 1 bad core that has them binned as 5820Ks.

Interesting observation!