**Official e8400/e8500 Retail OC Thread

[.OCX]

3 Hour Screenshot
2 Hour Screenshot

400 STRAP
[BIOS SETTING]

Ratio CMOS Setting : 9
FSB Frequency : 444
FSB Strap to North Bridge : 400
PCI-E Frequency: 100
DRAM Frequency: DDR2-1186
DRAM Command Rate : 2T
DRAM Timing Control: Manual 
5-5-5-15
DRAM Static Read Control: DISABLED
Ai Clock Twister : STRONG
Transaction Booster : ENABLED
Boost: 0
Performance Level: 7

CPU Voltage : 1.28125v
CPU PLL Voltage : 1.5v*
North Bridge Voltage :1.59v 
DRAM Voltage : 2.34v
FSB Termination Voltage :  1.20v*
South Bridge Voltage : 1.05v*
Loadline Calibration : ENABLED
CPU GTL Reference : .61
North Bridge GTL Reference : .63
DDR2 Channel A REF Voltage : DDR2
DDR2 Channel B REF Voltage : DDR2
DDR2 Controller REF Voltage : DDR2
SB 1.5V Voltage : 1.5v*

*Lowest Bios Setting Available in 0907

-Added High CFM Fan directly to DRAM.
-Changed DDR2 Channel A & B REF Voltage to "DDR2"
-This increased the DRAM REF Voltage in Hardware Monitor from (Auto@1.184v) to (DDR2@1.23v)
-DRAM installed in White Slots to get around DETDRAM issues when Overclocking, helps overall DRAM Stability.
-Limited on 400 Strap due to RAM

-1.28125v VCORE is the Exact Same Setting I use for my 333 Strap Stable@ddr2-1068 that is also currently in use for this 400Strap Stable@ddr2-1186.

[nzbleach]

ok guys , be careful with voltage. My E8200 4G Stable at 1.5Vcore is no longer prime stable. Just a warning to all you guys running higher than 1.45... dont!

[GLENBOY]

Not a clue about degration because ive not got these chips for that long. Gave mine between 1.80v and 1.95 for hours yesterday though benching on LN2. Prime on air stil runs fine at same vcore as before...

go on loco give it some stick i have had 3 e8*** chips no degradation for me so far benched 1.6volt on water then downclocked and still runs at lower speeds at same volts my own feeling is orthosing or priming at more than 1.35 volts is harming the chips but thats just my opinion

[user1234]

new rig, new sig

[dropglock]

Maybe I missed something, but are you sure you have degradation. There's not much difference between getting an hour vs 30min. Maybe the ambient is a little higher this time. I can run Orthos for an hour at 4.3G at 1.35v vcore, but if I have the heater running in the room, it fails after 30min. Turn off the heater and let the room cool down and its back to an hour.

On load it was running at 72-77 degrees when it failed. When it passed It was around the same thing. But a post by unclewebb say that temperature's are least of the worries. Also isn't 1 hour of OCCT more stress than Prime or Orthos at 1 hour? I've read a couple of posts saying that. One even in this thread saying that 1 hour of OCCT can find errors better than running orthos for 6+ hours.

I guess what I meant was you are still in VID range of cpu vcore, but 25% above suggested VTT FSB. And ? if high VTT FSB is just as bad as high vcore, and ? of stress testing with high VTT FSB is especially bad.

Could you raise vcore a little, and drop VTT FSB to 1.25 or 1.2 and get stable. And then see if you get any further degradation.

Anyways I increased the NB voltage to 1.450 and its 1 hour OCCT stable now. Before it was...
1.425 NB Voltage

Now to try increasing vCore and lowering VTT FSB voltage.

EDIT: Failed orthos in less than 5 minutes when increasing the vCore from 1.35-1.4 with VTT FSB of 1.225

[PhilDoc]

On load it was running at 72-77 degrees when it failed. When it passed It was around the same thing. But a post by unclewebb say that temperature's are least of the worries. Also isn't 1 hour of OCCT more stress than Prime or Orthos at 1 hour? I've read a couple of posts saying that. One even in this thread saying that 1 hour of OCCT can find errors better than running orthos for 6+ hours.

This all maybe true, wasn't trying to compair stress testing, but find the reason for your failed OC.

[HeadOn]

must have been a bios issue, because after updating to the latest on dfi's site, i'm now happily running OCCT on this:

1.312v on load

Can you post all your bios voltage settings? Thanks!

[unclewebb]

Just finished some very interesting testing tonight with the IR thermometer and I think I've uncovered the core temp mystery with these chips.

Absolute Temperature = TjMax - DTS

The value of TjMax is not publicly documented for any of the Intel desktop processors and there is no magic bit that any software can read to determine this value. That's why whenever a new chip comes out, CoreTemp takes a guess and some times gets it wrong. DTS is the value put out by the on chip digital thermal sensors and shows you how far the chip is from the throttling point.

The programmer of CoreTemp bumped TjMax up to 105C for the E8x00 desktop processors. TjMax=105C is fully documented by Intel for the mobile processors but I don't believe it applies to the desktop 45nm core duo processors. After numerous runs up to the throttling point, I'm convinced that TjMax=95C for the E8x00 desktop series. The maximum Tcase temperature has been bumped by approximately 10C between the early Conroe processors and the E8x00 so it makes sense that TjMax was also bumped from the original 85C to 95C but not to 105C.

The DTS in my E6400 provided very accurate absolute temperature readings based on TjMax=85C over a 35 degree range from 50C to 85C. The same is true for my E8400 but the 35 degree range is now from 60C to 95C. Below that range the actual temperature vs the DTS based temperature diverge by approximately 5C so at a DTS temp of 40C the actual was only about 35C. The E6400 would also diverge by about 5C at very low idle temps but it ended up reporting temps that were too low. I'm not sure if Intel has made a correction for the E8x00 or if the DTS is simply not accurate at low idle temps and has a margin of error of approximately +/- 5C at idle for all core processors.

You can't adjust TjMax using CoreTemp but the latest beta version of SpeedFan 4.34b38 is reading the 8x00 processors. It assumes that TjMax=100C so you have to go into Configure->Advanced and set the Temperature 1&2 offset to -5 and check the "remember it" box for both cores. This sets TjMax=95C. You will finally have some very accurate core temperature readings from 60C to the throttling point at 95C. These sensors were not designed or calibrated for reporting idle temps so some inaccuracy down low should be expected.

dropglock: If you are running at default MHz then an E8x00 will run stable well past 70C. If you are overclocking and are getting near the maximum then you will probably need to leave yourself at least 25C of headroom before the throttling point to maintain stability. Temperatures are only unimportant if you are Prime stable.

[Damien]

This isn't really processor related so I apologize, but i'm trying the 333/800 divider which would make the ram 600mhz and it's working fine at 2.35v, but super-pi isn't any faster. am i really running 600mhz or is it a bug? it's d9 so maybe :o

[laragirl83]

2 Hour Screenshot

400 STRAP
[BIOS SETTING]

Ratio CMOS Setting : 9
FSB Frequency : 444
FSB Strap to North Bridge : 400
PCI-E Frequency: 100
DRAM Frequency: DDR2-1186
DRAM Command Rate : 2T
DRAM Timing Control: Manual 
5-5-5-15
DRAM Static Read Control: DISABLED
Ai Clock Twister : STRONG
Transaction Booster : ENABLED
Boost: 0
Performance Level: 7

CPU Voltage : 1.28125v
CPU PLL Voltage : 1.5v*
North Bridge Voltage :1.61v 
DRAM Voltage : 2.34v
FSB Termination Voltage :  1.20v*
South Bridge Voltage : 1.05v*
Loadline Calibration : ENABLED
CPU GTL Reference : .61
North Bridge GTL Reference : .63
DDR2 Channel A REF Voltage : DDR2
DDR2 Channel B REF Voltage : DDR2
DDR2 Controller REF Voltage : DDR2
SB 1.5V Voltage : 1.5v*

*Lowest Bios Setting Available in 0907

-Added High CFM Fan directly to DRAM.
-Changed DDR2 Channel A & B REF Voltage to "DDR2"
-This increased the DRAM REF Voltage in Hardware Monitor from (Auto@1.184v) to (DDR2@1.23v)
-DRAM installed in White Slots to get around DETDRAM issues when Overclocking, helps overall DRAM Stability.
-Limited on 400 Strap due to RAM

-1.28125v VCORE is the Exact Same Setting I use for my 333 Strap Stable@ddr2-1068 that is also currently in use for this 400Strap Stable@ddr2-1186.

Man, running orthos is out of date, not to mention u were using priority 1... that is nothing!
If you want to stick witk Orthos, then run two instances of it, Small FFT's test, with priority 9!!
If your rig can take 5+ hours, then ur CPU probably able to that freq!

But still, i would recommend to use Prime95 v25.6!

[rge]

Just finished some very interesting testing tonight with the IR thermometer and I think I've uncovered the core temp mystery with these chips.

Absolute Temperature = TjMax - DTS

The value of TjMax is not publicly documented for any of the Intel desktop processors and there is no magic bit that any software can read to determine this value. That's why whenever a new chip comes out, CoreTemp takes a guess and some times gets it wrong. DTS is the value put out by the on chip digital thermal sensors and shows you how far the chip is from the throttling point.

The programmer of CoreTemp bumped TjMax up to 105C for the E8x00 desktop processors. TjMax=105C is fully documented by Intel for the mobile processors but I don't believe it applies to the desktop 45nm core duo processors. After numerous runs up to the throttling point, I'm convinced that TjMax=95C for the E8x00 desktop series. The maximum Tcase temperature has been bumped by approximately 10C between the early Conroe processors and the E8x00 so it makes sense that TjMax was also bumped from the original 85C to 95C but not to 105C.

The DTS in my E6400 provided very accurate absolute temperature readings based on TjMax=85C over a 35 degree range from 50C to 85C. The same is true for my E8400 but the 35 degree range is now from 60C to 95C. Below that range the actual temperature vs the DTS based temperature diverge by approximately 5C so at a DTS temp of 40C the actual was only about 35C. The E6400 would also diverge by about 5C at very low idle temps but it ended up reporting temps that were too low. I'm not sure if Intel has made a correction for the E8x00 or if the DTS is simply not accurate at low idle temps and has a margin of error of approximately +/- 5C at idle for all core processors.

You can't adjust TjMax using CoreTemp but the latest beta version of SpeedFan 4.34b38 is reading the 8x00 processors. It assumes that TjMax=100C so you have to go into Configure->Advanced and set the Temperature 1&2 offset to -5 and check the "remember it" box for both cores. This sets TjMax=95C. You will finally have some very accurate core temperature readings from 60C to the throttling point at 95C. These sensors were not designed or calibrated for reporting idle temps so some inaccuracy down low should be expected.

dropglock: If you are running at default MHz then an E8x00 will run stable well past 70C. If you are overclocking and are getting near the maximum then you will probably need to leave yourself at least 25C of headroom before the throttling point to maintain stability. Temperatures are only unimportant if you are Prime stable.

Interesting, thanks for the research...btw there is a discussion between the author of coretemp and intel engineer on this very subject, here...

http://softwarecommunity.intel.com/i.../30244450.aspx

[laragirl83]

Anyone having second thoughts about p5b-deluxe is the FSB Queen still?!

[rge]

Man, running orthos is out of date, not to mention u were using priority 1... that is nothing!
If you want to stick witk Orthos, then run two instances of it, Small FFT's test, with priority 9!!
If your rig can take 5+ hours, then ur CPU probably able to that freq!

But still, i would recommend to use Prime95 v25.6!

orthos stresses both cores, just like prime 95, only reason to run 2 instances is when testing quad.

using orthos custom, you can set small ffts to 8-64k, etc. and test same as newer version of prime 95.

Regarding priority, you are not testing anything different by using priority 9 instead of 1. (Reasons for using say priority 5 might be to circumvent problems with a screensaver that uses priority 4.) Partial explanation of priority on faq at prime95 site, quote below(orthos is prime95 with GUI)

"The operating system does an excellent job of giving all spare CPU cycles to the program. The only thing that raising the priority will do is make your other jobs less responsive. For example, lets say during the next minute your spreadsheet needs 10 seconds to recalculate. If your spreadsheet is running at a higher priority, then it will take 10 elapsed seconds to display its results. Prime95 will then get the remaining 50 seconds of the minute. If they run at equal priority, then the spreadsheet will get 10 of the next 20 elapsed seconds before it displays its results. Prime95 also gets 10 of the first 20 seconds as well as the remaining 40 seconds. In both cases prime95 got 50 CPU seconds, but in the first case you saw your spreadsheet results faster. " http://www.mersenne.org/faq.htm#faster

And if you dont believe the authors of the program, because you think because its difficult to work on another program using priority 9, therefore it stresses the system more (which is simply a result of affinity), you can test it yourself.

run tests at priority 9 and then 1 at known unstable settings. for example on one of my tests, a setting that orthos stopped in 10 minutes at priority 1, ran 11 minutes at priority 9. no difference, just one minute of variability.

[NINaudio]

I had my chip prime stable for 19 hours with 1.344 vcore, 1.55v NB, and 1.4v FSB termination. I had tried with slightly lower vcore and orthos failed at 9 hours 24 minutes and 27 seconds.

I lowered my NB to 1.4v, and fsb termination to 1.3v. Orthos failed at 9 hours 24 minutes and 27 seconds! Exactly where it did when the vcore was a bit too low. I bumped my NB back up to 1.55v. Surfed the net a bit, played some games, started Orthos, and went to bed. I awoke to a blue screen for irql not less or equal in iastor.sys. I turned it off and went to work. I'm going to try another run with my original settings and see what happens, unless you guys have some other suggestions?

[laragirl83]

orthos stresses both cores, just like prime 95, only reason to run 2 instances is when testing quad.

using orthos custom, you can set small ffts to 8-64k, etc. and test same as newer version of prime 95.

Regarding priority, you are not testing anything different by using priority 9 instead of 1. (Reasons for using say priority 5 might be to circumvent problems with a screensaver that uses priority 4.) Partial explanation of priority on faq at prime95 site, quote below(orthos is prime95 with GUI)

"The operating system does an excellent job of giving all spare CPU cycles to the program. The only thing that raising the priority will do is make your other jobs less responsive. For example, lets say during the next minute your spreadsheet needs 10 seconds to recalculate. If your spreadsheet is running at a higher priority, then it will take 10 elapsed seconds to display its results. Prime95 will then get the remaining 50 seconds of the minute. If they run at equal priority, then the spreadsheet will get 10 of the next 20 elapsed seconds before it displays its results. Prime95 also gets 10 of the first 20 seconds as well as the remaining 40 seconds. In both cases prime95 got 50 CPU seconds, but in the first case you saw your spreadsheet results faster. " http://www.mersenne.org/faq.htm#faster

And if you dont believe the authors of the program, because you think because its difficult to work on another program using priority 9, therefore it stresses the system more (which is simply a result of affinity), you can test it yourself.

run tests at priority 9 and then 1 at known unstable settings. for example on one of my tests, a setting that orthos stopped in 10 minutes at priority 1, ran 11 minutes at priority 9. no difference, just one minute of variability.

I didnt know that!

[Infa]

Just finished some very interesting testing tonight with the IR thermometer and I think I've uncovered the core temp mystery with these chips.

Absolute Temperature = TjMax - DTS

The value of TjMax is not publicly documented for any of the Intel desktop processors and there is no magic bit that any software can read to determine this value. That's why whenever a new chip comes out, CoreTemp takes a guess and some times gets it wrong. DTS is the value put out by the on chip digital thermal sensors and shows you how far the chip is from the throttling point.

The programmer of CoreTemp bumped TjMax up to 105C for the E8x00 desktop processors. TjMax=105C is fully documented by Intel for the mobile processors but I don't believe it applies to the desktop 45nm core duo processors. After numerous runs up to the throttling point, I'm convinced that TjMax=95C for the E8x00 desktop series. The maximum Tcase temperature has been bumped by approximately 10C between the early Conroe processors and the E8x00 so it makes sense that TjMax was also bumped from the original 85C to 95C but not to 105C.

The DTS in my E6400 provided very accurate absolute temperature readings based on TjMax=85C over a 35 degree range from 50C to 85C. The same is true for my E8400 but the 35 degree range is now from 60C to 95C. Below that range the actual temperature vs the DTS based temperature diverge by approximately 5C so at a DTS temp of 40C the actual was only about 35C. The E6400 would also diverge by about 5C at very low idle temps but it ended up reporting temps that were too low. I'm not sure if Intel has made a correction for the E8x00 or if the DTS is simply not accurate at low idle temps and has a margin of error of approximately +/- 5C at idle for all core processors.

You can't adjust TjMax using CoreTemp but the latest beta version of SpeedFan 4.34b38 is reading the 8x00 processors. It assumes that TjMax=100C so you have to go into Configure->Advanced and set the Temperature 1&2 offset to -5 and check the "remember it" box for both cores. This sets TjMax=95C. You will finally have some very accurate core temperature readings from 60C to the throttling point at 95C. These sensors were not designed or calibrated for reporting idle temps so some inaccuracy down low should be expected.

dropglock: If you are running at default MHz then an E8x00 will run stable well past 70C. If you are overclocking and are getting near the maximum then you will probably need to leave yourself at least 25C of headroom before the throttling point to maintain stability. Temperatures are only unimportant if you are Prime stable.

Is this a fact that i can count on? how sure are you on this?
it do make sense though.. and i like that my temps are 10c lower, now it as i said, makes sense is this a value that we "people" should go after from now on? or what do you say, nice find anyway

regards.

[grsz06]

Just installed e8400 in Commando with 1605 and it won't post. Came from e6600, cmos cleared...any ideas what I can do to get to post?

[Viss]

Whats does display tell? After cmos vdimm is set back to 1.8v You might wanna try booting up with only 1 dimm in bank closest to socket to get into bios and set vdimm.

[laragirl83]

Whats does display tell? After cmos vdimm is set back to 1.8v You might wanna try booting up with only 1 dimm in bank closest to socket to get into bios and set vdimm.

Exactly!

[grsz06]

Never thought to look at lcd. It says cpu init. Did I get a bad one? I have tried one dimm etc.

[laragirl83]

Never thought to look at lcd. It says cpu init. Did I get a bad one? I have tried one dimm etc.

So cmos cleared, battery were taken out for a few seconds and all?

[grsz06]

Left batt out for 10 mins...still no post.

[Monstru]

Retail E8400 Q746A

4954Mhz Cpu Validation ON AIR
4900Mhz Spi 1M ON AIR
Link

4000Mhz @ 1.28v - Orthos
4150Mhz @ 1.33v - Orthos

It can be stable at much higher clocks (with appropriate volts) but I am more interested in benching than stability testing

[Viss]

Left batt out for 10 mins...still no post.

Take hsf off, cpu out and back in, helped me before with cpu init thingie...

[Danger30Q]

E8400 on air (Tuniq Tower)
DFI 680I motherboard
1.356 vcore
1.44 northbridge
9x444 = 4.0ghz
Stable with 30 minutes OCCT testing

I haven't tried anything higher yet but I'm quite happy with 1.356V on air is great at 4.0ghz.