I just want to touch on something i've seen mentioned in other forums and seems to maybe have some merit with my testing and observations with my ASrock and Asus setups.
. . . . . . . . .
Anyway, as i said, its the wife's birthday and i've gotta get off of here before she smashes my pc.. :biggrin:
You'll be back.
It may be that there's confusion afoot. If you don't fix the VCORE in BIOS and take it off "Auto," you aren't going to see the idle voltage of the overclock. With Turbo over-clocking, and especially with EIST enabled, you'll only see the voltage at EIST, and you'll only see the drooped and loaded voltage under load. In BIOS, with turbo enabled, you'll see the vcore reported as the stock-clock voltage plus your saved Offset value. These are going to be lower.
Or it may be, for the same reason, that if it's easier to overclock some other boards with fixed VCOREs in BIOS, they're talking about the unloaded over-clock voltage while we're referring to the loaded over-clock voltage.
But it wouldn't be in ASUS' [just ASUS, after all . . ] interest to use sensors or misinterpret sensors at downwardly-biassed levels. If damaged chips were attributed to the company, they'd lose business on the motherboards.
Incidentally. Either I made an error in reading my notes for the 4.53 Ghz over-clock settings, or the last time it ran Large FFT PRIME95, it ran without error as a fluke. Either the OFfset needs to be bumped up 0.005V, the "Vxtra" needs to go up by 0.004V, or LLC needs to be set to "Medium." I'll annotate my last post with a correction.
For your mention of the 4.8 clocking and about it "working" and needing more voltage tweaks -- I assumed as much. It increases the value of your information with the listed OC's to know that. But we're right on the same frequency about "how far to go."
One thing I discovered -- you can go hours and hours with Small FFT and get an error or BSOD in less than an hour of Large FFT.
I think we're all weary of marathon final runs of PRIME95. Supposedly, IBT was supposed to mitigate this by allowing you to run 10 or 20 iterations or so in an hour. But I also discovered that IBT runs can seem to prove stable, and then a couple hours of PRIME disproves it.
Fact is, with the new components they're using -- solid state capacitors and other features -- an OC setting is less likely to "go south" over an extended time on these newer boards. So even if your settings were right on the edge under stress, the processor is never going to run in that loaded condition during normal use. Even so -- a testament to some OC'ers perseverance that we seem to want absolute certainty confirmed. But I try to get testing out of the way as soon as possible.
john3850 said:
{I was told Supposedly stabilizes frequencies under noise conditions.}Enabled
Now what causes noise high temps.
I got the cheapest mb and I am stable 4.7 with 1.39-140v on load.
At 4.8 I get a few errors needs more tweaking.
I run both computers with in six feet of ac or 75f degrees room temp.
Now I bet your problem is related to temp or vcore.
I would set your LLC 1 step below the highest or ultra.
Try vcore on auto and test.
Then in cpu-z under load I want to see to a vcore of 1.39-141v for 4700.
I assume you're referring to the PLL Overvoltage. Yeah. That was my take on it. "Overvoltage" may scare some people off, but this just beefs up the control circuit to further stabilize frequencies.
I've been testing in varying but monitored room-ambients -- mostly ranging from 78F to 84F. During the tweaking process, I'll typically undervolt the processor until it's "just over the edge." Then, after I've run stress-tests, I'll bump up a critical voltage one notch.
I'm really quite sure I've got a biassed sensor on the chip. I've still followed the rule of thumb that "what the sensor says is what you have," but I'm pretty sure otherwise. The TM1 throttling spec is 72.6C and hinged to "TCASE" in the Sandy Bridge spec at Intel. But when you have a grouping of three core temperatures at 65C, 66C and 65C, while Core #1 is showing as 72C, and the software shows a PKG temperature (TCASE?) that is equal or great to the Core#1, the tight grouping of the largest number suggests one core temperature and possible TCASE are out of whack.
Of course, someone might argue that maybe Core #1 has a different loading or it's "busier" or some other explanation, but if the same degree of bias between the cluster and the single outlier show up at idle, that wouldn't be the case eiter.
If as someone suggested that "TCASE" doesn't exist, then there would have to be an algorithm to compute "PKG." Either way, either the biassed core or the TCASE could be "off." This has been observed for some time now. We had sensors for Wolfdale that were stuck at 51C when the system was at idle, and would only rise above that to what you'd expect under load. Then there was Intel's disclaimer, noting unreliability of the sensors at idle, and more general "intel" indicated that sensors could be giving readings with error. Supposedly they aren't meant to be more accurate that +/- 4C, and you may find one that is outside that level of error. I'm sure of it.
EDIT: Just dawned on me. If I think the temp sensor is biassed upward, but I "want to follow a rule of thumb," then I should probably plan on getting a water-cool kit. Then, neither the rule-of-thumb, the bias or the uncertainty about "how much" wouldn't matter. The only thing that would matter then -- as a "rule of thumb" -- would be voltage.
Facebook
Twitter