Real Temp - New temp program for Intel Core processors

Quote:

---

Originally Posted by Dua|ist

Yes, thanks rge. Your testing is detailed and useful as always. :clap: The info on Northwood temp calculations was also very educational. :yepp:
I must admit you beat me. But then we just have to admit that Target TJ values for 65nm are plain wrong... Or Intel means something else with these new numbers. :shrug:

P.S. The thermal specification formula is quite interesting too. It could explain why newer steppings have higher TCasemax temps (relative to their TJunction temps). If the psi (or theta?) value is a constant, then due to lower power consumption (TDP) of the new stepping we get less difference (gradient) between TCasemax & TJunction. This makes me think that TCasemax might be some kind of "secondary" value, calculated (or measured) based on TJunction temperatures, as it isn't a whole number.

---

Well actually it was yours and others questioning that got me to do the videos and more testing, which I learned something from....so thank you. Also I think vids are helpful in that unless you see it yourself you always wonder.

Jaredpace...the max gradient you will likely encounter is 26C, intel tests this under worst case conditions with stock cooling, hence if you stay 26C from tjmax, you are likely always within tcase spec (if you overclock with stock cooler you increase it, but offset it by better cooling). Once you are less than 26C from tjmax, you may or may not be in spec, depending on the loading program, hence intel states the gradient is variable and can not be used to predict tcase. But as Unclewebb has pointed out, under those situations where you are pushing the limits, to get stability you will probably need to maintain such a distance from tjmax anyways. Another way to look at it if your core is 74C...you know your Tcase is significantly lower...and at that point the rule of every 10-15C you drop your temp, you double life of your component becomes more important especially when overclocking with high voltage.

One interesting side note from all the testing, I am now sure of 6-7C (can not be more than 8 or less than 5) over ambient for high end water or air cooling at low volts, idle, speedstep on or 6x333. I can set cpu temp to exactly track IHS reading as long as I stay at idle, same tdp. No question the IHS is 3C over ambient on water and 6C over ambient with intel stock cooling. The gradient from core to IHS is max 5C at those conditions, but I am convinced it drops by 20% with intel heatsink on and high box fan speed, and more with high end cooling (max 50% decrease) . It would not surprise me if the entire gradient were halved comparing water to intel stock cooling where core is ~10-12C above ambient at those conditions with stock cooling.

Thanks rge. I've run out of thumbs up for all of your testing. It helps everyone understand the gradients that exist and goes further than my testing that was always done at idle without a heatsink installed.

I still read in forums about users running Prime95 with reported core temperatures of ~60C but their heatsinks don't even feel warm. Now we know why. The heat dissipates rapidly from the source when a heatsink is installed.

It confirms TjMax=100C is correct for the E8400 and that the RealTemp calibration method at low MHz / low core voltage, is valid for users that want more accurate core temperatures. It might need to be adjusted by a degree or two based on your recent testing so could you create a small chart showing what temperatures a user should aim for when calibrating? Intel OEM, aftermarket air and water. I might have some fun with my drill this week to see what I can learn. :)

I'm thinking about getting an e8400 and running it at greater than 1.45v-1.50v actual and/or higher than 80C load. Just to see what will happen, since I really haven't heard of anyone doing this and reporting back. I have a feeling it will just degrade the cpu over time making it require more volts to achieve the same megahertz, while producing more heat in the process. But in the meantime, I could probably run 4.8ghz 24/7! :ROTF:

Quote:

---

Originally Posted by unclewebb

Thanks rge. I've run out of thumbs up for all of your testing. It helps everyone understand the gradients that exist and goes further than my testing that was always done at idle without a heatsink installed.

I still read in forums about users running Prime95 with reported core temperatures of ~60C but their heatsinks don't even feel warm. Now we know why. The heat dissipates rapidly from the source when a heatsink is installed.

It confirms TjMax=100C is correct for the E8400 and that the RealTemp calibration method at low MHz / low core voltage, is valid for users that want more accurate core temperatures. It might need to be adjusted by a degree or two based on your recent testing so could you create a small chart showing what temperatures a user should aim for when calibrating? Intel OEM, aftermarket air and water. I might have some fun with my drill this week to see what I can learn. :)

---

Thanks, I enjoyed all the testing as I know you do...great educational hobby. As for calibrating idle temps, after all my testing I was looking for a reference and saw one of your old posts that already correctly estimate idle temps for high end cooling.:D. But I can list what I found for water, zalman, and intel stock.

Interestingly, the gradient with intel stock cooler at low volts idle is ~10-11C. If you then turn a box fan on high (15inch fan at high rpms).. you lower temps and drop gradient 2C, more effective cooling compresses temp range and corresponding gradient becomes smaller...that is not exactly the way I imagined gradients before testing. And yep the gradient to the heatsink is huge.

To calibrate idle temps for core 2 duo: First set vcore 1.1V bios +/-~.03v and 6x333 mhz manually or leave speedstep enabled. Then set idle so it reads listed degrees above ambient for given cooling:

COOLING...............................IDLE DEGREES ABOVE AMBIENT
High end water...............................6C above ambient
High end air (true push/pull) ........6-7C
High end air (1fan).........................7C
Mid air (zalman 9500)....................8-9C depending on fan rpm
Intel stock cooler...........................10-11C

Need to use listed volts for calibrating, increasing volts significantly will widen the gap between better and worse cooling and alter the gradients.

Edit: I will have to leave quad estimating to you, i dont have one.

rge: Your testing confirms what I was thinking during some informal testing I did a couple of days ago.
#2395

Quote:

---

I'm suspicious that my assumption that a well air cooled Core 2 Duo should run about 5C hotter than ambient at low MHz and low voltage might be too conservative. Maybe our calibration method at low volts / low MHz should be based on 10C.

---

Looks like the truth is somewhere in between. Your chart will provide users with a baseline when calibrating no matter what type of cooling they're using and I will include this info in the updated documentation with a link to what's been learned during testing.

For a Quad like my Q6600 - G0, I think I would add 2C to your numbers. Time for some more testing.

I've just started comparing power consumption to core temperatures which might help users with calibrating and checking for sticking sensors. Now that we have a baseline it will be easier coming up with answers about Quads, etc. based on power consumption.

By adjusting Clock Modulation in MSR 0x19A, you can also create a nice graph comparing core temperatures at different power levels while running a consistent stress program like Prime95 small FFTs. I'll include this option in the next RealTemp for testing purposes.

Anyone interested in checking this out can use my MSR program to set model specific register 0x19A like this for each core:

12.5% -> 0x12
25.0% -> 0x14
37.5% -> 0x16
50.0% -> 0x18
62.5% -> 0x1A
75.0% -> 0x1C
87.5% -> 0x1E

To return your processor to full power set MSR 0x19A to 0x02

The percentages aren't exact but if you step through different power levels while running Prime you should see your core temps go through different steps. If the temps don't change equally between cores then I think this new test should help confirm sticking sensor issues or maybe even slope error issues. It's a work in progress.

E6600 @ 2.7GHz

http://i176.photobucket.com/albums/w...PowerLevel.png

Core #0 was occasionally slower at changing temp than Core #1, but was always within 1C. Temps reported using RealTemp 2.79.8

EDIT: I suppose I should say what I used for loading the CPU ;) Prime95 small FFTs.

Quote:

---

Originally Posted by rge

If all you are interested in is distance to tjmax, then yes this information is useless. But if it upsets you in some way for those of us interested in absolute temps, why not just ignore it, instead of needing to post you dont give a "flying f" about it?

---

I didn't disparage your testing in any way, if you actually read what I wrote. I said I don't care what IHS temps are as long as the heatsink is working and keeping the processor inside acceptably cool, which is surely the situation for most of us. Thank you for twisting my words. :mad:

And have you never heard the phrase "devil's advocate"? I was asking what most casual readers will be wondering after that theoretical jargon and testing, which is how does it help improve our understanding of temps reported by the DTS, which is what this thread IS about (ie. RealTemp). If it improves the calibration possibilities, then explain how. It was a simple enough question. :shrug: Now it seems to have been answered. :up:

Now, the question is, can this be incorporated into Realtemp to make calibration even easier and foolproof for most users? For example, consider a calibration "wizard" that would check the processor is idling as specified, confirm the cooling spec and ask for an ambient temperature to be entered... and presto the setting is done without editing INI files and requiring user hunches (assuming sticky sensors are not detected). That's a practical result from this which is an achievable goal. ;)

Ian, did not mean to misconstrue your words, miscommunication happens all time on net as cant decipher tone, I meant no offense and none taken. Goal is to understand the slope error, idle temp range, and gradient from IHS to core to get accurate temps across the range, and I think it is very possible to do. And as Unclewebb stated, the same info will need to be applied to Nehalem as intel states the errors are still there just to a lesser degree. Also it is especially important for 65nm, since intel has not released the large offsets needed to be added to tj target to calculate accurate 65nm temps

Unclewebb...like the power consumption graph...will have to play around with that

I just got my E8600 10 mins ago, even if upgrading to nehalem in 4-6 months or sooner, I want a good backup computer, and my E8400 has had too much abuse.

My last test on E8400 will be drill rest way through to core,...so may be down few days. Only problem, I will have to recalibrate for surface reading since I cant drill a hole in core to put thermocouple tip in, like I did with IHS (at least wont try that until all other testing)...but I can get exact absolute gradient by apples to apples comparison from thermocouple coated in thermal paste touching flat core vs flat IHS, as the small error is constant. I can calibrate that error exactly with IR (just few C) and and then read absolute temps by subtracting known small error.

OK Uncleweb I need some clarification.

After Intel releases the TJ max of their processors I currently have a Q6600 what is the correct TJ Max that I have to set in RealTemp.? BTW I am using the Beta version.

Right now since I saw 90 thats what I set the TJ Max. my temps currently are 30 29 27 30 with ambient of 20.5 C. IS that correct? Did I made the correct change from 100 tj max to 90?

Ill appreciate clarification I really like RealTemp tool over Speedfan, Coretemp etc.

Thanks

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.

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.

By the time I get an accurate Automatic Calibration feature finished, they'll be retiring Core i7. :)

randomizer: Nice graph. Maybe automatic calibration isn't as far off as I thought. It's pretty easy to see what your idle temps are going to be at the next step when load is 0%.

Quote:

---

Originally Posted by unclewebb

It's pretty easy to see what your idle temps are going to be at the next step when load is 0%.

---

Scary thought isn't it? I believe I was hovering around 53C before I ran prime95 :eek:

randomizer: What I found during testing is that if you leave MSR 0x19A set to 0x12 and then stop Prime95 your temps will drop down one more step and then while idle if you set MSR 0x19A back to the default 0x02, your temps will drop another degree or two. I think it lets your processor go into a slightly lower power state but don't quote me on that. With my Kill-a-Watt meter plugged in, power consumption drops a couple of watts.

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.

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.

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:D. 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.

Quote:

---

Originally Posted by unclewebb

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. :shrug:

Quote:

---

Originally Posted by unclewebb

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 :D

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.

http://i176.photobucket.com/albums/w...k_manager1.png

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

Quote:

---

Originally Posted by 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.

---

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... :confused:

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 :D), 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 :rofl:) 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 :rofl:. 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... ;)

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.

Quote:

---

Originally Posted by 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.

---

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

Quote:

---

Originally Posted by 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? :confused: 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. :shrug: 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? :ROTF:

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.

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.

Quote:

---

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.

Quote:

---

Originally Posted by unclewebb

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.

Quote:

---

Originally Posted by 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.

---

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.

Quote:

---

Originally Posted by unclewebb

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 :)

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.

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 :D).

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...

oops double post

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.

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.

http://img46.imageshack.us/img46/1112/tempinfogb3.png

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.