• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.
  • The forums have been upgraded with support for dark mode. By default it will follow the setting on your system/browser. You may override it by scrolling to the end of the page and clicking the gears icon.

Intel Core i5 & i7 Sandy Bridge Overclocking and Feedback

Subbed for info and the mysterious cadaveca's overclocking secrets. :)
 
Well what are people using for stress testing? I do 100 runs standard on IBT with avx. Then 50 runs max, and 20 runs forced to 8 threads. 5 hours OCCT large data set. Then memtest 5-9 passes whenever needed. Despite all that I like many others end up with random BSODs, assumingly due to vdroop. Typically throwing excessive volts at it fixes it, just isn't very efficient.
 
Last edited:
well...

Never experienced this problem. Sounds like bad overclock testing, IMHO, crashing at idle. There are ways to avoid that, very obvious ways, actually.

Well what are people using for stress testing? I do 100 runs standard on IBT with avx. Then 50 runs max, and 20 runs forced to 8 threads. 5 hours OCCT large data set. Then memtest 5-9 passes whenever needed. Despite all that I like many others end up with random BSODs, assumingly do to vdroop. Typically throwing excessive volts at it fixes it, just isn't very efficient.

Well let's just say I've tried all BIOS available for my mobo. And that the crashes happen in intervals, like a timer. So if I had an x amount of vcore, it will determine how long my system stays on and during that time I can stress test the CPU using LinX 25 passes or Prime 12 hours if I have pumped enough volts into it and it will crash the next day IF I don't have enough volts.

The message I get is Bug check 0x124 every crash in event viewer, I mean if someone can give me tips that is fine, but I am not doing anything out of the ordinary at the moment other than adding vcore and turning LLC to moderate to minimize vdroop.
I am confident that my chip is stable at 1.320 Vcore but it sucks I need 1.360-70 to keep it from crashing for days @ 4.5ghz and personally I think that is quite poor results.

I've done memtest on my two sticks for 4 hours and found no errors as well, I've very well also ruled out every other hardware in my system and came down to the conclusion I've posted above. From my standpoint there is really not much else I can do, I've tried all different methods out there available and the only one that seems to work is putting in more VCORE, I agree it is NOT efficient hence why I am frustrated with the platform right now because there doesn't seem to be any other way.

If there is then fire away I'm all ears mateys.

EDIT: What I haven't tried actually is OCing via software, there are obvious reasons as to why I've stayed clear from that but after reading Cadavecas results, I'll give it a go when I get home tonight and see if I can get varying results.
 
Last edited:
Well what are people using for stress testing? I do 100 runs standard on IBT with avx. Then 50 runs max, and 20 runs forced to 8 threads. 5 hours OCCT large data set. Then memtest 5-9 passes whenever needed. Despite all that I like many others end up with random BSODs, assumingly do to vdroop. Typically throwing excessive volts at it fixes it, just isn't very efficient.

Well let's just say I've tried all BIOS available for my mobo. And that the crashes happen in intervals, like a timer. So if I had an x amount of vcore, it will determine how long my system stays on and during that time I can stress test the CPU using LinX 25 passes or Prime 12 hours if I have pumped enough volts into it and it will crash the next day IF I don't have enough volts.

The message I get is Bug check 0x124 every crash in event viewer, I mean if someone can give me tips that is fine, but I am not doing anything out of the ordinary at the moment other than adding vcore and turning LLC to moderate to minimize vdroop.
I am confident that my chip is stable at 1.320 Vcore but it sucks I need 1.360-70 to keep it from crashing for days @ 4.5ghz and personally I think that is quite poor results.

I've done memtest on my two sticks for 4 hours and found no errors as well, I've very well also ruled out every other hardware in my system and came down to the conclusion I've posted above. From my standpoint there is really not much else I can do, I've tried all different methods out there available and the only one that seems to work is putting in more VCORE, I agree it is NOT efficient hence why I am frustrated with the platform right now because there doesn't seem to be any other way.

If there is then fire away I'm all ears mateys.

EDIT: What I haven't tried actually is OCing via software, there are obvious reasons as to why I've stayed clear from that but after reading Cadavecas results, I'll give it a go when I get home tonight and see if I can get varying results.

I think some of the issue is early adoption. Even though manufacturers have released several bios, it is still early in the game. Like I mentioned before, I've seen improvements in vdroop over the last couple of beta bios that I've received straight from a Biostar rep. Maybe Cadaveca has some undiscovered magic, maybe not, but the board partners are learning and making changes that will help stabilize the platform. I'm fairly confident in that, from what I've seen so far.

I think we also need to learn from each other and experiment to see what works and what doesn't. That's one of the things that makes this hobby fun. Be patient, experiment and have fun. For those of you who have been in the game for awhile know that we really have it easy these days when tweaking hardware. I try hard not to take it for granted.
 
Last edited:
I think some of the issue is early adoption. Even though manufacturers have released several bios, it is still early in the game. Like I mentioned before, I've seen improvements in vdroop over the last couple of beta bios that I've received straight from a Biostar rep. Maybe Cadaveca has some undiscovered magic, maybe not, but the board partners are learning and making changes that will help stabilize the platform. I'm fairly confident in that, from what I've seen so far.

I think we also need to learn from each other and experiment to see what works and what doesn't. That's one of the things that makes this hobby fun. Be patient, experiment and have fun. For those of you who have been in the game for awhile know that we really have it easy these days when tweaking hardware. I try hard not to take it for granted.

I apologize to anyone who have picked up that I am being a tad ungrateful and impatient, I'm still trying to get used to this platform as I've only begun from clocking a Q6600 and Nehalem which had very similar methods. Paul, your posts have made me very hopeful and more comfortable sticking to what I have, Gigabyte have not released any new BIOS downloads since I bought my board so I will have to be a bit more patient.

I'm receiving my B3 stepping motherboard at the 18th of this month so despite the board being the same as my current without the degrading issue I am also hoping that it will also help me with my issue. Although there is also a chance that I may have just received a really poor chip and that maybe most badly binned chips have the same symptoms.
 
I apologize to anyone who have picked up that I am being a tad ungrateful and impatient, I'm still trying to get used to this platform as I've only begun from clocking a Q6600 and Nehalem which had very similar methods. Paul, your posts have made me very hopeful and more comfortable sticking to what I have, Gigabyte have not released any new BIOS downloads since I bought my board so I will have to be a bit more patient.

I'm receiving my B3 stepping motherboard at the 18th of this month so despite the board being the same as my current without the degrading issue I am also hoping that it will also help me with my issue. Although there is also a chance that I may have just received a really poor chip and that maybe most badly binned chips have the same symptoms.

Yeah, way too early to panic about things. Gigabyte seems to get things right after a few bios revisions, at least from my experience with the x58 platform. Also, from what I have seen you don't have a really bad chip. You just might not have a really good chip. ;). That would likely include 60-70% of all 2600k's. Hell, I went through a half dozen i7 920 chips before I found a really good one, then another half dozen for another. It's just how it goes. However, you can work to squeeze everything possible out of that chip, and it will give you more processing power then you will probably ever really need.
 
Speaking of, what's the cut off on this rma stuff? As long as I'm using 1155 I'm not changing out this board. Soonest swap I'd do is bulldozer if it can beat sandy, which is a few months away. I just don't have a need for more than 4 ports. I don't have a backup system... and there's no way I'd buy another 1155 board in advance.
 
Speaking of, what's the cut off on this rma stuff? As long as I'm using 1155 I'm not changing out this board. Soonest swap I'd do is bulldozer if it can beat sandy, which is a few months away. I just don't have a need for more than 4 ports. I don't have a backup system... and there's no way I'd buy another 1155 board in advance.

Don't know about a cut off. Most manufacturers are doing an advance RMA. They send you the board, secure it with a credit card, then you send the old one back after you switch them out. ;). Im going to have to wait until April for my replacement. Biostar will not have replacements for this board until then. :banghead:
 
What I haven't tried actually is OCing via software, there are obvious reasons as to why I've stayed clear from that but after reading Cadavecas results, I'll give it a go when I get home tonight and see if I can get varying results.

The problem exists that this software I am using needs bios-level support in order to function fully. Explore the CD that came with your board, and maybe it's there for you.

124 error code, in your situation, may be memory controller volts.

stole this lsit form elsewhere her on TPU:

BSOD codes for overclocking
0x101 = increase vcore
0x124 = increase/decrease QPI/VTT first, if not increase/decrease vcore...have to test to see which one it is
on i7 45nm, usually means too little VVT/QPI for the speed of Uncore
on i7 32nm SB, usually means too little vCore
0x0A = unstable RAM/IMC, increase QPI first, if that doesn't work increase vcore
0x1A = Memory management error. It usually means a bad stick of Ram. Test with Memtest or whatever you prefer. Try raising your Ram voltage
0x1E = increase vcore
0x3B = increase vcore
0x3D = increase vcore
0xD1 = QPI/VTT, increase/decrease as necessary, can also be unstable Ram, raise Ram voltage
0x9C = QPI/VTT most likely, but increasing vcore has helped in some instances
0x50 = RAM timings/Frequency or uncore multi unstable, increase RAM voltage or adjust QPI/VTT, or lower uncore if you're higher than 2x
0x109 = Not enough or too Much memory voltage
0x116 = Low IOH (NB) voltage, GPU issue (most common when running multi-GPU/overclocking GPU)
0x7E = Corrupted OS file, possibly from overclocking. Run sfc /scannow and chkdsk /r
 
The problem exists that this software I am using needs bios-level support in order to function fully. Explore the CD that came with your board, and maybe it's there for you.

124 error code, in your situation, may be memory controller volts.

stole this lsit form elsewhere her on TPU:

BSOD codes for overclocking
0x101 = increase vcore
0x124 = increase/decrease QPI/VTT first, if not increase/decrease vcore...have to test to see which one it is
on i7 45nm, usually means too little VVT/QPI for the speed of Uncore
on i7 32nm SB, usually means too little vCore
0x0A = unstable RAM/IMC, increase QPI first, if that doesn't work increase vcore
0x1A = Memory management error. It usually means a bad stick of Ram. Test with Memtest or whatever you prefer. Try raising your Ram voltage
0x1E = increase vcore
0x3B = increase vcore
0x3D = increase vcore
0xD1 = QPI/VTT, increase/decrease as necessary, can also be unstable Ram, raise Ram voltage
0x9C = QPI/VTT most likely, but increasing vcore has helped in some instances
0x50 = RAM timings/Frequency or uncore multi unstable, increase RAM voltage or adjust QPI/VTT, or lower uncore if you're higher than 2x
0x109 = Not enough or too Much memory voltage
0x116 = Low IOH (NB) voltage, GPU issue (most common when running multi-GPU/overclocking GPU)
0x7E = Corrupted OS file, possibly from overclocking. Run sfc /scannow and chkdsk /r

Good list to have. I think that the majority of the idle BSOD experienced by Sandy Bridge owners is 0x124.
 
It's interesting, my last couple bsods had no error code. Which seems like it can mean a few things. On that note, thanks. My BSOD code list was missing a few of those.
 
I can't take credit for that list, nor do I know exactly how accurate it is, but at least it gives some direction.
 
That reminds me, has anyone seen any codes specific to pll? Or will that register as a vcore issue.
 
I haven't had any bsods. Auto settings at 4.5GHz may be setting the vcore higher than it needs but it has definitely been very stable.
 
I haven't had any bsods. Auto settings at 4.5GHz may be setting the vcore higher than it needs but it has definitely been very stable.

Yeah, if you are on auto, I'm fairly sure your vcore is too high. Can you post a cpu-z screenie, and load temps?
 
Just did some more research during lunch and it seems the new revisions have fixed the LLC and vdroop problems. I'll hopefully be picking up my new B3 stepping board today, I'll give an update on how it goes.


EDIT: The boards went on sale today without me knowing, there is less than 5 left on their site www.itestate.com.au so I am lucky I didn't wait til the 18th lol.
 
Last edited:
I just tried the max LLC setting, it doesn't mess around. With 1.36v in the bios it jumps to 1.368-1.378 under load, compared to 1.328-1.336 on the next highest setting. It occurs to me though isn't this not remotely helpful to the issue? The problem is bsods during no load, web browsing and crap. LLC only kicks in under higher load, doesn't change idle behavior.
 
Yeah, if you are on auto, I'm fairly sure your vcore is too high. Can you post a cpu-z screenie, and load temps?

On Auto with offset voltage, it tends to predominantly load @ 1.34/1.35v with very momentary spikes up to 1.37v but no higher. I mean, I can game for an hr/2 hrs whilst having HW monitor running and it will show 1.34 as the highest voltage but fire up 3DMark 06 and it will always have a momentary shift upto 1.37v. LLC is on Auto also.

Load Temps under Prime after a couple of hours are around 68-70c but then I'm running my fans through resistors for a nice quiet setup. Gaming wise it stays under 60c always.

Freaking awesome chips really.:rockout:

EDIT - Will get some screenies up at some point and it's nice to finally have a Sandy Bridge thread going on here :)
 
Alright finally! I am able to go back to my old methods of OCing. The main problem was... with my Gigabyte board, LLC overshot Vcore I was getting temps from 80-90's when I set vcore to 1.370 LLC Level 1 but with the new B3 stepping mobo I got today, on level 1 LLC temps are under 75 with 1.370 vcore.

More evidence, on my old B2 stepping UD5 I was able to boot into windows using 1.315 with Level 1 LLC... Now on my B3 stepping It will only reach loading screen til it BSODs with the same settings... So this to me has indicated that the LLC for my old B2 stepping was pushing Vcore higher than what I put in the BIOS and in turn made vdroop and everything else harder to deal with and it also explains the higher thermals.

With B3 everything seems to be in working order, I have a pretty average or below average chip that needs 1.370vcore for 24/7 4.5ghz settings but the temps are under 75 so I am okay with that and also I haven't received a crash on idle at all yet and I doubt I will now since LLC has been fixed.
 
Last edited:
I feel kinda dense. I suddenly get why overclocking with power states could be more effective. The phantom bsods are from idle vdroop at high clock-rates. Being at idle means LLC doesn't kick in to compensate. If you're idling at 1600mhz you eliminate that issue as the only time you're at max speed is under load, when LLC supposedly kicks in. I say supposedly because I just ran a test with a 15% load, LLC didn't kick in which could be a serious roadblock to this solution. You may end up only with the illusion of increased stability because you spend considerably less time at your max overclock in idle voltage conditions.

Other than that the problem is there's been many reports of c-states hurting your performance, so that extra 100-300mhz you get out of it could easily be negated by having them on.
 
My 2600k is at 4700Ghz single core, 4600 dual core, 4500 triple and quad core. It was running 4700Ghz fine with rather toasty temperature, so I lowered it to a lower level, along with a lower vcore.

I do presume you mean mhz... 4700ghz would be crazy!
 
I feel kinda dense. I suddenly get why overclocking with power states could be more effective. The phantom bsods are from idle vdroop at high clock-rates. Being at idle means LLC doesn't kick in to compensate. If you're idling at 1600mhz you eliminate that issue as the only time you're at max speed is under load, when LLC supposedly kicks in. I say supposedly because I just ran a test with a 15% load, LLC didn't kick in which could be a serious roadblock to this solution. You may end up only with the illusion of increased stability because you spend considerably less time at your max overclock in idle voltage conditions.

Other than that the problem is there's been many reports of c-states hurting your performance, so that extra 100-300mhz you get out of it could easily be negated by having them on.

Even when I had the C-state functions on or off, the main problem was with LLC not the Vdroop. The LLC was broken, it over compensated and none of those power saving features would help my stability, it would still inevitably crash and BSOD even if the processor was idling at @1.6 ghz. LLC was the main reason why I could boot and bench under 1.315-25 but at high temps, the real vcore MUST have been much higher during load than what I set in the BIOS which would cause the instability when my system went to idle at lower voltages.
 
You would bsod at 1.6ghz? Did you have offset turned off? Offsets don't seem to work right with LLC. Other issue is we're not all using the same boards let alone bios, so behaviors will differ significantly in some cases.
 
You would bsod at 1.6ghz? Did you have offset turned off? Offsets don't seem to work right with LLC. Other issue is we're not all using the same boards let alone bios, so behaviors will differ significantly in some cases.

Offset? If you are referring to dynamic vcore usage, I was not using that. I was inputting Vcore directly. Gigabyte has been known to have problems with LLC in their p67 motherboards, BUT this is only concerning B2 stepping motherboards which I assume everyone has already replaced anyway.

My new B3 has none of these problems present and LLC works as intended now without overshooting Vcore, hence my report of improved temps overall. Never passing 71-72 degrees whereas on my older motherboard it reached around 80-85 with the exact same settings.
 
I have been binning a few here are some results

so8ffr.png


r8cyzm.png


241lcnp.png
 
Back
Top