Real Temp - New temp program for Intel Core processors

[rge]

Used a flat head bit to drill through IHS to core (pic 1). Shiny part of the hole on left is top die, on right barely drilled into top of die/mold compound, not deep like it looks. Spent about 4 hours testing so far...may make vids this weekend if have time, have couple made, but not the interesting stuff.

The idle temps above in post 2429 are right on the mark.

The magnitude of the gradients is confirmed, their location I was wrong about. There is a significant layer of die/mold compound over the DTS core and cpu sensors, and the majority of the gradient (60-65%) occurs across that layer to top of die, the rest of the gradient occurs across IHS and tim1.

................................Sensor die temp.........thermocouple DIE temp............Thermocouple IHS temp
NO HEATSINK
IDLE 6x266, 1.1v-----100C (DTS=0)------------------97-98C----------------------------94-95C
LOAD 6x266, 1.1v-----77C-----------------------------70C--------------------------------65C

stock cooler
LOAD 9x333, 1.2V-----68C-----------------------------58C--------------------------------51-52
at higher volt setting to allow higher temp...load returns to idle, once again software sensor reads only few C higher than thermocouple to top of die, (2-3C gradient at idle low volts, confirmed by varying voltage and watching gradient changes).

The testing from the university (pic2 below or slide 22 link) http://www.ee.ucr.edu/~stan/papers/todaes07_softsen.pdf shows exactly the same thing regarding location of the gradients, despite testing a northwood. The only difference is the cpu diode in northwood with much larger die size better tracked IHS temp, whereas on 45nm the cpu diode better tracks core temp ?minus a few C.

The core and cpu sensors are close together on die on 45 and 65nm hence you see little gradient (5C max 65nm) from core to cpu sensor. You will not see core to core gradient for same reason plus there are multiple DTS sensors everywhere, only hottest reported, which makes gradients much less likely to be visible "horizontally".

This actually makes sense once you play around with it for awhile. You are actively cooling IHS, copper transmits heat instantaneously, hence relatively small gradient across IHS which has high conductivity close to cooling mechanism, but still gradient increases across the IHS with load as expected. The majority 60-65% of the gradient is without question through mold compound located over the die/cpu sensors and under the top of the die where thermocouple measures tem....just like pic in university shows, was with orthos anyways, but as the university pics show, the gradient location and magnitude can vary depending on loading program. The copper laden die/mold does have a high thermal conductivity around ~125 W/M*K, but still roughly 1/3 of that of copper 390 W/M*K, so top of die is well cooled via IHS compared to further into die.

Edit: also on weekend I will try to run an actual thermocouple die temp versus software core temp to get idea of slope error. But at idle, since half gradient is across IHS and half across mold and constant 5C gradient regardless of temp...frankly this can be done simply by measuring IHS temp and adding 5C to it...drilling hole with thermocouples is not necessary.

[randomizer]

Your graph shows that your sensors are working fine and aren't sticking. There's no way my E6400 - B2 is TjMax=70C like Intel has recommended but for your E6600, it looks possible. Did you ever do the low MHz / low voltage test? I'll go look back a few pages. I'd try TjMax = 70C or 75C and see how things look during this test. Now that rge has cleared up what the low end should look like and Intel has given us some guidance on what TjMax might be, maybe you can finally make some sense out of your sensors.

Just so you know, the idle temp of 53C was with C1E enabled, but EIST disabled. The two don't seem to tango with my motherboard, I end up stuck with a 6x multi. So I would be running at 1800MHz and 1.130V as reported by CPU-Z. I can't manually lower my vcore below VID. Right now I'm idling at 48C as it's a little cooler today. I haven't used the RealTemp calibration because at least for a Tj Max of 90C I don't think the adjustment ranges are quite large enough hehe. With a 70C Tj Max it would be 2-3C above ambient.

If my E6600 isn't TjMax 90C then it must be nearly one-of-a-kind because most people's temps seem to fall into typical ranges, whereas mine is always higher. Heck, on a day where the ambient temp in my room would have been around 15C (which is uncommon here), my CPU was still idling supposedly at 32C. Perhaps the early batches had a different Tj Max even though they were the same stepping? This is only a week 28 chip.

How do you like the ability to manipulate the power level your CPU is running at? Prime95 small FFTs is my fav for keeping the power level consistent. Anyone with sticking sensors that plots a graph like you did will end up with the lower part of the graph going horizontal but yours looks good. I plan to add power level adjustment into RealTemp for testing in the near future and then maybe have it test automatically and draw a nice graph like you showed us sometime in the future.

Funny you should mention this, I was going to suggest this in my previous post but decided you probably had better things to do

EDIT: I don't know a whole lot about how this works, but C1E seems to have a fit when you change the power level. With an MSR 0x19A value of 0x16 or 0x14 the CPU alternates a 6/9x multiplier as well as the vcore very frequently even when I'm not doing anything. At 0x12 it is almost consistently running the higher settings and therefore the idle temp difference between 0x12 and 0x16 is no more than 1C. Is it because the maximum power level is so low that C1E "thinks" it is running a high load when usage is around 3% at the most? Task manager would confirm this, because if I set core #1 to 0x12 and core #0 to 0x02 then even a small load appears greater on the graph for core #1. If both are set to 0x12 then moving the task manager window appears to cause 50% utilisation on each core, whereas it is normally around 4%. If you look below, both cores show the same basic graph, but core #1 is much more pronounced.



I'm just trying to work out exactly what is happening when you change the power level.

[IanB]

IanB: Automatic calibration would be a wonderful thing but I don't think it's possible. There are just too many unknowns starting with the latest curve ball Intel threw at us at the recent IDF. I haven't quite figured out what TJ Target really means and I probably never will. Then there are sticking sensors, slope error and Intel calibration error at TjMax, both of unknown magnitudes, and etc., etc.

OK, I get that. But what I've taken from the discussion up to a few pages ago was that there is an unknown fudge around TjMax at the top end, where the sensors are supposed to be more accurate, then there is a bad slope with increasing error down to the low end where the sensors are definitely not accurate, giving extremely unreliable readings. But the last few pages seem to have provided a clear way to calibrate this low end very accurately, which should be possible by confirming the underclock state and getting the user to input cooling type and ambient temp, so at least one end of the graph, which previously was the worst end, can now be more or less dead accurate. Am I wrong here?

Calibrating the high end is going to be impossible without some form of active temp measurement, I agree, along with a routine that can stress the processor until it throttles at a known distance from TjMax. But at least that end is supposed to be more accurate. If the DTS is officially based on TjMax, now published, does this new figure of TjTarget even matter? Ironically it seems this relationship to TjMax is being lost in the pursuit of this new obfuscation from Intel...

Here's a thought - given rge's testing of the gradients from core to IHS to heatsink, suppose someone were to market a cheap piece of kit - effectively a really BAD (or modded cheap) heatsink with a thermosensor mounted optimally in the base, linked to a simple thermometer gizmo that records the max temp measured. Now you have a stressing routine that breaks at PROCHOT asserted, you have a known DTS measurement this occurs at, and a known IHS temp this occurs at on a given chip. Wouldn't this fix the high end of the graph effectively without requiring ANY of these speculative and unreliable documented temp specifications, INCLUDING TjMax?

For any really avid overclocker (looks around at a captive and hungry market ), this should be fairly simple to use to calibrate a given chip on a once-only basis, is obviously capable of reuse on newer sockets/processors with slight software upgrade and simple mounts (heck, make it compatible with the TRUE and 90% of the users here wouldn't even need any ) and it should be dirt cheap to make and still be pretty accurate for this purpose. Given what some people here are prepared to waste, um "invest", on graphics cards and SSDs, I can see a definite opportunity for someone with an engineering interest...

EDIT: Just wanted to add that the current method of calibration at the low end (underclock and idle) works without hardware, but isn't very useful for "normal" use as that point on the graph is way below "normal" usage, which is rarely going to be massively underclocked and idle for most people here . If you had such hardware, it would be simple to have a piece of software that confirmed system idle at normal clocks and got a DTS reading/temp for that, then did the same for a 50-60% system load, then did the full stress routine to throttling. You'd then have three confirmed points on the graph to make a really accurate DTS/temp curve for each core covering the likely usage range, which might be importable into RealTemp somehow...

[rge]

Ian, after you set the correction to idle temp in Real temp using low volts and idle you have made the DTS sensors pretty accurate all the way up the scale. So once you overclock again, the actual temp goes up as do the sensors, in fact once fixing idle error since realtemp has slope error correction built in, thermocouple core reads temps same as realtemp all the way up, within ~1-2C error.

[IanB]

Ian, after you set the correction to idle temp in Real temp using low volts and idle you have made the DTS sensors pretty accurate all the way up the scale. So once you overclock again, the actual temp goes up as do the sensors, in fact once fixing idle error since realtemp has slope error correction built in, thermocouple core reads temps same as realtemp all the way up, within ~1-2C error.

You'll appreciate my confusion as this apparently contradicts the previous reply from unclewebb:

IanB: Automatic calibration would be a wonderful thing but I don't think it's possible. There are just too many unknowns starting with the latest curve ball Intel threw at us at the recent IDF. I haven't quite figured out what TJ Target really means and I probably never will. Then there are sticking sensors, slope error and Intel calibration error at TjMax, both of unknown magnitudes, and etc., etc.

If an auto-calibration of the inaccurate low end is possible in the way I suggested, which seems reasonable from your results, you have just confirmed that it would then be accurate all the way up the scale, assuming the TjMax value used to fix the top end is legitimate. That was my understanding too, that the top end DTS scaling was more accurate and therefore reliable.

So where is the impossibility? It just seems a logical extension of the current sensor testing routine to me that removes a little of the user error possible in initial calibration by "guessing" offset values to put manually in the INI file. You can read the chip voltage, the FSB speed and system load to confirm the correct underclock setting for calibration, then get user input on the cooling setup and ambient temps and use your gradient calculations to convert the current DTS to an actual temp. It seems dead simple to me, sorry. Isn't that what computers are supposed to be good at, doing calculations to remove guesswork and save time for their users?

Obviously if all that is required is the low end calibrating properly, then there's no need for elaborate (even if cheap) hardware to compare actual IHS temps with direct DTS readings.

[unclewebb]

randomizer: I think it was rge that had a theory that perhaps TJ Target and the actual TjMax were very similar during early manufacturing but as the process matured, the actual Tj Max for the B2 processors might have been bumped up a few times by 5C notches. Intel has been telling us since day 1 that we can't use these sensors to report accurate core temperatures and if TjMax was being quietly adjusted then that might explain the big secret. I haven't played with the Clock Modulation settings with C1E enabled yet. I'll give it a try.

IanB: You make some good points. It was always my belief that if you did a RealTemp calibration at a fixed low power level that you would end up with some reasonably accurate temperatures from idle to 60C where most users run their CPUs most of the time. rge's work and recommendations improves upon that.

assuming the TjMax value used to fix the top end is legitimate.

And there is the problem. The latest IDF news release has shown me that Target TJ values and TjMax may not necessarily be the same thing. The RealTemp calibration will automatically minimize a couple of degrees of error in TjMax but it can't compensate for a 20C error in TjMax.

For most of the mainstream 45nm processors that Intel says are TJ Target 100C, we now have two fixed points on the temperature curve and with a calibration, you can get accurate core temperatures from idle to TjMax.

Unfortunately the whole calibration concept really hasn't caught on even amongst the hard core community at XS. It's very rare that I see a screen shot posted where the calibration feature is being used. The majority of users seem comfortable accepting the fudged up DTS sensor data as is and don't want RealTemp fudging their data to make it look nice.

100% accurate temperatures aren't that important with Intel Core processors anyway. If you're overclocking and not stable at full load because of too much heat then you need to buy a bigger super cooler or reduce your MHz and / or core voltage so that your Distance to TjMax headroom increases. If you're stable and not thermal throttling, you can safely ignore your core temperature.

[pifive]

pifive: There are two different versions of the Q6600:

Stepping B3 - CPUID 0x6F7 - TjMax = 90C
Stepping G0 - CPUID 0x6FB - TjMax = 100C

A program like CPU-z will show you what stepping you have and RealTemp will show you one of those two CPUIDs.

At the recent IDF, Intel has said that the TJ Target for these processors is 80C and 90C. To be honest, I'm not quite sure what that means or the relationship to TjMax.

My opinion is that for accurate core temperatures, you need to use a +10C offset from this Intel spec so the latest beta of RealTemp is still using 90C and 100C. Click on the Defaults button in the RealTemp Settings window and it will show you what your default TjMax is. Your reported temps look realistic to me but you would need to give me a lot more details about your case and cooling used and MHz and core voltage and........ Try doing the RealTemp calibration procedure as outlined in the docs.

Thanks Unclewebb. I have a g0 overclocked to 3.0 ghz Vcore 1.26 VID is 1.250. My case is a Lian LI PC-A60C doesn't yield a good cooling for overclocked systems but is good. My temps are 40 - 39 - 36 - 38 idle with now the TJMax of 100.

Thanks for response.

[randomizer]

randomizer: I think it was rge that had a theory that perhaps TJ Target and the actual TjMax were very similar during early manufacturing but as the process matured, the actual Tj Max for the B2 processors might have been bumped up a few times by 5C notches. Intel has been telling us since day 1 that we can't use these sensors to report accurate core temperatures and if TjMax was being quietly adjusted then that might explain the big secret.

That theory works well with the B2 stepping at least. I intend to try and find the answer to this, as well as what Tj Target actually is and how it relates to Tj Max. I managed to accidentally catch the attention of some Intel engineers, so we'll see.

For most of the mainstream 45nm processors that Intel says are TJ Target 100C, we now have two fixed points on the temperature curve and with a calibration, you can get accurate core temperatures from idle to TjMax.

This is good to hear, considering a few weeks ago you were saying it wasn't possible at all

[unclewebb]

The testing by rge has renewed my faith in these sensors. They're not all bad. I've always had pretty good success but some of the recently released Intel documentation was making it seem more like a hopeless cause. I thought they were bashing them so we'd run out and buy some new Core i7 CPUs.

I originally thought TjMax was a lot more fixed than what it might turn out to be. At least TJ Target helps explain why some processors like your E6600 don't make any sense when using traditional values for TjMax. Now we just need more users to do some calibrating so it catches on.

[randomizer]

Intel did say that Target Tj can be changed, but if Target Tj is Tj Max, then a 20C change is pretty drastic. It's certainly beyond what I would consider a part-by-part calibration. It could indicate a huge improvement in the heat tolerance of the process I suppose. What Intel needs to do if Tj Max is changed alot is:

1) Give us all of the different values that were used in the past (and future would be nice too ).

2) Tell us when they were changed. At least if a user looks at what week their CPU is, they could work this out. Of course, this assumes that Intel changed the Tj Max for the entire stepping at certain points which might not be the case.

Of course, if that huge difference is just part-by-part calibration...

[rge]

oops double post

[rge]

There is no cpu, early pentium, 65nm, or 45nm that has a gradient less than 20-25C between tcase and hotspot (DTS) on full TDP load at stock settings, however there was a 10C gradient between cpu diode and tcasemax on pentiums prior to DTS being fully implemented.

My pentium 4 that I drilled a hole in has a tcasemax of 69C. It throttles then cuts off at a 80C controlled by cpu diode not DTS (hot spots), so it has ~11C gradient from tcasemax to tj target using cpu diode. But the cpu diode on a pentium underestimated load hot spots by 15+C (per research paper in earlier post) and this tjunctionoffset in pentium docs was defined as max difference between cpu diode and hot spots (pic of doc below). The pentium throttling at tj target of 80C by cpu diode (11C gradient cpu diode to tcase) knowing hot spots were 15C higher (tjunction offset) is no different then setting tj target 95C by DTS (26C gradient DTS to tcase).

Then came DTS sensors that accurately captured the hot spots, additionally the cpu diode started approximating hot spots more closely via die shrink (65nm intel temp research paper). Initially cpu diode (not DTS sensors) were still being used for throttling control even after early incorporation of DTS. I now have no doubt the original tj target on 65nm were planned to be 10C based on cpu diode temps, prior to fully switching to DTS for throttling control, and prior to research on 65nm samples illustrating the decrease offset between hot spots (DTS) and cpu diode and the proven ability to accurately capture hot spot temps.

Intel stated that the DTS was calibrated upward to prevent throttling below tcasemax, which means all cpus that were made with that requirement based on DTS throttling not cpu diode have a tjmax at least 20-25C higher than tcasemax, quads a few C higher based on 45nm known values. The fact that my E6850 tjmax was 98-100C by IR, and unclewebbs E6600 was tjmax 90C by IR...to me puts the issue to rest for more recent models, especially given slide 7 and 13 with graphs showing large offsets. I just dont know exactly when DTS sensors became the throttling control instead of cpu diode (and when docs changed to reflect this), and when the research was done (only know when published) so that intel knew the exact gradients, relationship, and DTS accuracy for hot spots so they could aggressively set tj via DTS.

[unclewebb]

Thanks for the background info rge.

From what I've read, I thought the first DTS sensors were introduced into the late Pentium 4 CPUs but I haven't found any users that could read this data from their P4. Anyone that wants to try can use my MSR Tool and read MSR 0x19C where the temp info hides.



Those two digits contain the DTS data and should decrease as the core temp goes higher. It would be interesting to see those numbers go up and down on a late P4 when the load changes. You'll have to manually click on the Read MSR button to check for any changes.

Edit: rge, I was just reading the P4 docs and it shows the IA32_THERM_STATUS MSR just like the Core processors use but there was no mention of this MSR containing any temperature data. The two bits of data in this MSR that RealTemp uses to report Thermal Status as OK, LOG or HOT when thermal throttling is active and listed as functional in the P4. If you want a version of RealTemp that will work with a P4 to at least read this information then let me know. The temps will be meaningless but those flags should light up. It would be interesting next time you do some P4 testing.

[rge]

Unclewebb, would have loved to have that ability to use realtemp to read that reg on P4 prior to its current state...I had bright idea in my drilling phase to guess at a non critical place to drill deep into the core to compare to surface of core, funny thing it still works computer sounds like its booting windows...but no video...but also carelessly broke 3 pins on edge from not protecting them while drilling...may try something metal to replace pins as may not be the hole but pins causing lack of video...if I get it fixed I will let you know.

[randomizer]

rge, how many CPUs do you have lying around to drill?

[rge]

http://www.xtremesystems.org/forums/...postcount=2394
pic of 3 drilled, my E8400 makes 4th (post 2438), my E7200 would be 5th but fried it running it delided trying to measure temps that way, which I learned is impossible...the IHS is an incredibly effective heatsink and heatspreader...last recorded temp on my E7200 was 138C (thermal monitor disabled) still dont know if it shorted or fried from heat... but my E8600 I just got is not getting touched, except having fun seeing what it can do Besides at this point I am confident I would not learn anything else, just see same gradient, so I have already satisfied my curiosity...so no more drilling...probably.

[randomizer]

And people are afraid to run prime95 when they hit 60C... WITH a heatsink.

[unclewebb]

rge: When you get bored playing with your new E8600 maybe I'll send you my Pentium E2160 for a drill job and some testing. It only has 1MB of cache and compared to the E8400 with 6MB, the E2160 heats up very slowly without a heatsink on it. Nice HTPC type chip. I sometimes prod it with some Prime action to get the temps up there but even with no heatsink or fan, the temps drop quickly when you stop Prime. That IHS lid is definitely working. It might provide us with another calibration point for chips with smaller amounts of cache.

I'll probably drill one of those cheap, Intel OEM, all aluminum, low profile heatsinks first and see if I can get any usable data from it with the IR thermometer. I also have a consumer grade probe to shove in the middle of it but I don't know what quality of data I'll get from that.

[rge]

anytime...but if trying it there...I could not get temps through a drilled hole in a heatsink with IR, despite laser spot being small, but because the IHS is such a good heatspreader, placing any heatsink on 1/3 of the cpu IHS with paste and leaving the other 2/3 uncovered for IR, I could get accurate die temps (-5C gradient), even without drilling into a heatsink (after comparing that to drilled die temps). Doing it that way near 1.1 vcore, I am confident adding 5C (2-3C IHS and 2-3C across die mold from sensors) will get you accurate die temps the same as measuring top of die and adding 2-3C. At 1.4-1.5 vcore and idle like on the pentium or E8400 at that voltage you get a 4-5C gradient across IHS and 4-5C across die mold, anything in between can be extrapolated. Of course the one fallacy will be if as you say E2180 puts out a lot less heat, but I bet it is going to be similar, given the idle temp similarities in my pentium 4 and E8400, despite their differences in specs both simply scaled the same with voltage.

Or if tape half cpu for IR and put a pea size ball of thermal paste just next edge tape in center to completely envelop tip of thermocouple as pressed up against IHS and using different idle voltages to regulate temp, you can "calibrate" thermocouple ie if always reads 5-7C below IR temps (unless inserting thermocouple inside IHS) but need to "calibrate" at middle range and high range to make sure same error. But using that method, need to keep the thermocouple from moving to much as spinning it around can change calibration 1-2C.

[unclewebb]

Just to clear things up, I've heard from a reliable source that TJ Target and Tj Max are the exact same thing and that Intel wasn't trying to add more confusion to this subject.

I wrote back and tried to explain the problem I have with that:

"If I use TjMax=70C for my B2 I end up with idle temperatures during my calibration test that are reported approximately 17C below my room temperature and based on rge's recent testing that has to be a good 23C below the actual core temperature. There is a couple of degrees of slope error in the 65nm CPUs but certainly not that much.

There's the dilemma I have. If I follow Intel's recent guidelines for 65nm, I am going to end up with a lot of unhappy users and my program will likely become the laughing stock. Intel's version of things just doesn't seem to fit with the testing that rge and I have done on B2 and G0 Dual and Quad Core processors."

Based on that, I don't intend to change the TjMax that RealTemp is presently using for the 65nm processors. If an individual user thinks that the Intel recommended TjMax is correct for his CPU then by all means go ahead and use it. All I can say is that there seems to be a lot of 65nm processors out there that don't fit Intel's recent TjMax news release.


rge: I can't wait to fire up the drill and get back to testing but at the moment I'm trying to concentrate on the programming side. Initial testing of the new Core i7 looks good. They seem to have really tightened up the specs for their sensors.



45nm Intel Core 2 Duo owners can only dream about their temperatures looking that consistent both at idle and under load. This Core i7 Extreme 965 (ES) model is using TjMax = 100C. I'll improve processor recognition when I see some official Intel documentation.

The only sad part is they're going to put RealTemp out of business. Any software should be able to get some reasonably accurate core temperatures out of Core i7 without having to guess at TjMax or needing a calibration or correction factors or anything else. RealTemp 2.82 is reading the default TjMax info from within the CPU. As soon as I get confirmation that it is working properly, I will release the latest beta here.

Hmmm, upon further review, maybe there's still room for a little slope or TJ Target correction with Core i7.
Some sensor isn't being 100% honest.

[rge]

I wonder if it is a disconnect between intel person doing the explaining and the ones that actually know, or if they are simply leaving something out, like what tj refers to cpu diode or DTS, whether there are 15-20C offsets on 65nm and not on 45nm.

In addition to the idling subzero issue (low end ridiculous), I would send the intel person (if that is source) two pics (high end ridiculous as well). One, fluke IR demonstrating E8400 IHS temp is 5C lower than die temp using intels 45nm 100tjmax, which is very plausible. Second pic exact same fluke IR, exact same method, demonstrating an IHS defying the laws of physics being 15C hotter than the die using intels wacky 65nm tjmax....and as nicely as possible imply you will stop laughing when they can explain that. You can argue absolute error on IR (though couple C not like that), relative error you cant with a straight face.

Of note coretemp author isnt changing tj based on 65nm either.

Edit: let us know what they respond with...cant imagine

[Captn]

Is RealTemp 2.79.8 the latest version? I searched back like 10 pages and couldn't find anything newer, thank you in advance.

[unclewebb]

Hi Captn Sponge Bob. Long time no see around here. RealTemp 2.79.8 is still the last official beta. I've been taking it easy lately while the TjMax / TJ Target debate gets sorted out. I've added proper reading of TjMax from the new Core i7 processors recently but not much else. I might quickly add in throttling control to help users check for sticking sensors. I have a few ideas for some new features. I just need to find the time to implement them.

[Captn]

Hi Captn Sponge Bob. Long time no see around here. RealTemp 2.79.8 is still the last official beta. I've been taking it easy lately while the TjMax / TJ Target debate gets sorted out. I've added proper reading of TjMax from the new Core i7 processors recently but not much else. I might quickly add in throttling control to help users check for sticking sensors. I have a few ideas for some new features. I just need to find the time to implement them.

Does this CPU have the issue with the stuck temp sensors? http://www.newegg.com/Product/Produc...82E16819115041


When are the Core i7's do out ?

[sdsdv10]

When are the Core i7's do out ?

I have read dates between Nov 3rd and Nov 16th.

So somewhere between soon and very soon...