Temp question

Printable View

03-10-2007, 04:20 PM
jagatucci

Tcase/Tjunction/Temp question

I'm trying to figure out why my Tcase temp is higher than my TJuntion temp. I'm assumming one is being reported incorrently, but which one is more likely to be the culprit. Here's my situation:

Tcase = 37 (32 in BIOS upon restart) & 55 (up to 62 with TAT)
Tjunction = 32 & 50-55

Ambient = 20
Chipset = Nvidia 680i
C2D = e6400
CPU Cooler = Arctic Cooler Freezer Pro 7/Ceramique
Frequency = OCed to 3.2 (linked/synced with 1600QDR)
Load = Orthos/TAT/OCCT/3DMark2006
Motherboard = EVGA
Vcore = 1.25

I'm wondering, of course, why my Tcase is higher than my Tjunction. Is my TJunction more likely to be being reported incorrectly than my TCase? That is, is it likely that my Tcase is correct, meaning my TJunction Idle/Load values are really more like 47/70-75. The Tjunction values reported above are consistent across TAT, CoreTemp, and SpeedFan. Any guidance would be much appreciated.
03-10-2007, 06:46 PM
Lestat

Quote:

Tcase = 37 (32 in BIOS upon restart) & 55 (up to 62 with TAT)
Tjunction = 32 & 50-55

well first of all you dont own a board and there is no baord in exsistance that shows Tcase and Tjunction as the way you are saying. so i am not sure why your calling it that.

tcase and tjunction are for the oober geek and dont mean squat for normal ocing.

personally dont look at the tcase and such of TAT,
and dont forget TAT doesnt show CPU temps, it reads the onboard Core probe that is built into all conroe chips. that is built directly intot he cpu itself so temps are always, ALWAYS higher than any other temp program reads, as other programs read the outer probe or probe thats built into the board itself.
which can be 10c or more lower than TAT.

and that arctic Freezer isnt the best cooler around, its not horrible but for me i place it in the range of the stock cooler, but only slightly higher.
so dont expect spectacular temps with it unless its sitting outside your case buy an open window with the cold winter air blowing in.
03-10-2007, 07:41 PM
jagatucci

Hmmm

Ok, first off Tjunction refers to the diode between the two cores, while TCase is what is read off the top of the heatspreader. TAT shows you both cores (i.e., Tjunction; whichever Core is highest), as does Core Temp. SpeedFan shows you CPU (TCase) and both cores (Tjunction, whichever Core is highest). So, the board does, indeed, shows all of these values, though you might label them differently. This is why SpeedFan 4.32 shows a CPU temp and also two core temps. In general TCase temp should be 15 degrees below TJunction, but on my system in SpeedFan CPU (TCase) is usually seven degrees higher than both Core temps (Tjunction), which are usually around 31. It's this odd reading that generated my question. If you're unaware of the different temp values that C2D owners should be aware of, check out this thread at Tom's: http://forumz.tomshardware.com/hardw...ict221745.html
03-11-2007, 02:02 AM
GGuyZ

I don't know where you found this information, but it's really not accurate.

Tcase - Temp reading on the top center of the IHS.
Tjunction - Junction temperature between the Die and the PCB it sits on.

There are no temp readings for these values, besides constant values representing the Tjmax.
The DTS on each core outputs a negative result that is then substracted from the Tjmax.

I've read the guide in toms, and while it is quite thorough, it seems to me that it has many holes and erroneous information.
03-11-2007, 02:40 AM
bing

1 Attachment(s)

The correct temperature "terms" according to Intel

Here.., what a picture worth for .... according to Intel straight from their tech journal.

Attachment 56551

Red = Thermal goop
Brown = IHS
03-11-2007, 05:43 AM
mcoleg

oh, nice pix bing. mind if i use it? i often get in explaining why ppl shouldn't panic as they do about c2d temps and this one should be a handy visual aid :P
03-11-2007, 06:07 AM
nealh

Quote:

Originally Posted by Lestat

well first of all you dont own a board and there is no baord in exsistance that shows Tcase and Tjunction as the way you are saying. so i am not sure why your calling it that.

tcase and tjunction are for the oober geek and dont mean squat for normal ocing.

personally dont look at the tcase and such of TAT,
and dont forget TAT doesnt show CPU temps, it reads the onboard Core probe that is built into all conroe chips. that is built directly intot he cpu itself so temps are always, ALWAYS higher than any other temp program reads, as other programs read the outer probe or probe thats built into the board itself.
which can be 10c or more lower than TAT.

and that arctic Freezer isnt the best cooler around, its not horrible but for me i place it in the range of the stock cooler, but only slightly higher.
so dont expect spectacular temps with it unless its sitting outside your case buy an open window with the cold winter air blowing in.

very interesting...I found on my RD600 the cpu temps on TAT(5-10C lower) were the lowest..highest was Smartguardian and coretemp was in between
03-11-2007, 07:12 AM
bing

Quote:

Originally Posted by mcoleg

oh, nice pix bing. mind if i use it? i often get in explaining why ppl shouldn't panic as they do about c2d temps and this one should be a handy visual aid :P

Sure go ahead, its from Intel tech journal so its not mine anyway ! ;)
03-11-2007, 07:44 AM
sofarfrome

temp issues

The board I have got sent back to newegg because I thought I damaged a temp probe in CPU socket area when installing a tuniq 120 as both bios and smartguardian were reading ridiculous temps. I put it on water too and still, high temps.

I got the new board Friday and set it up yesterday and guess what, still ridiculous temps in bios and smartguardian. I have run the same CPU and HSF in both a Gigabyte DS3 and the P5N-E and idle temps are 33-35C and 49-52C under full orthos load after 8 hours (1.4vcore). I install everything on the DFI board and bios reads 48C idle and after about 4 hours of orthos temp is 80C. I installed Intel's TAT tool and when smartguardian is reading 77C TAT is seeing 57C on both cores. I think the board misrepresents the cpu temp but I sure don't want to destroy this CPU as it really clocks well at the lower vcore. Based on the picture above from Intel perhaps I should just ignore what SG and bios are telling me and believe in TAT (hey, maybe I can start a cult)...anyhow, I have contacted DFI but I really don't want to RMA another board as shipping is getting expensive.
03-11-2007, 08:07 AM
bing

Folks ! All those temp readings, mobo, tat, coretemp are "NEVER" accurate.

Of course the worst one is from mobo since nowday there is no real temp probe under the cpu like the old days, those mobo temp reading mechanism are using "approximation" and they're not calibrated at factory.

Even TAT or coretemp which reads from the core directly, those on die sensor are never calibrated accurately either. Temp readings might off with the range of +/-10 degree celcius.

Intel aware of that inaccuracy since they "assume" it is still safe margin as long you're running stock speed, and even with stock cooler, the CPU will be just fine running in the middle of hot desert air. :)

So want a peace of mind ? Don't OC, but again it denies your existance in this forum isn't it ? :D
03-11-2007, 08:08 AM
kwalker

TAT or thermal analysis tool was designed for the mobile platform where the readings were software readable off the msr.
Rely on the bios or motherboard software readings for your temps.
Intel stated the bios and their own monitoring software are within 3 Deg of accuracy.
Below is an explanation from Intel on the design and application of the DTS and thermal diode from a support forum
Long read but the support follow up post sums up the meaning nicely.

The processors with a processor signature (CPUID) of 00000F30h through 00000F64h implement the IA32_TEMPERATURE_TARGET (msr 1A2h). For those processors, IA32_TEMPERATURE_TARGET[15:8] is an offset value that must be added to a BASE value which is package dependent and is specified in the appropriate data sheet for the processor. For most but not all, the BASE value is 50C.

For those processors, it is assumed that temperature measurements are obtained from the thermal diode which is connected to base board management controller that also contains a fan speed controller. If the temperature read via the diode is above the BASE + IA32_TEMPERATURE_TARGET[15:8] (offset) then the processor fan is expected to be operating at it’s maximum RPM. Any temperature below that is below base + offset may scale the fan speed down.

Note Tj is not a fixed value and the IA32_TEMPERATURE_TARGET[15:8] value can vary from part to part. Tj is also not software readable.

For the processors with a processor signature of 000006Fxh and 0001066xh the IA32_TEMPERATURE_TARGET[15:8] specifies an offset (below) the PROCHOT# assertion point. For these processors the relative temperature is read via the PECI interface by the base board management controller that also contains the fan speed controller. In the case of the PECI interface the fan speed controller knows that it must spin the fans at their max RPM if the value read from the PECI interface is less than the value from IA32_TEMPERATURE_TARGET[15:8]. Any value greater than IA32_TEMPERATURE_TARGET[15:8] read on the PECI interface indicates the processor is not operating in a hot condition and the fans can be scalled back to a lower RPM.

To support transition mainstream desktop platforms where PECI may not be supported or implemented the Conroe processor (Intel® Core™2 processor) added the BASE + OFFSET method used by the Pentium® 4 processor and temperature reading via the thermal diode. However the OFFSET value is loacated in the THERM_DIODE_OFFSET register (msr 3Fh). THERM_DIODE_OFFSET contains a valid bit and an offset value. If THERM_DIODE_OFFSET[7] is set to 1, then THERM_DIODE_OFFSET[4:0] contains a valid offset value which can be used to program the fan speed controller using the BASE + OFFSET. If THERM_DIODE_OFFSET[7] is cleared to 0 then the thermal diode method of reading the processor temperature and controlling the fans is not available.

Some steppings of the mobile Intel® Core™2 processor do indicate Tj to be approximately 85 or 100 via a single bit in the EXT_CONFIG register (msr 0EEh) but desktop, workstation and server processors do not. Nor is there a register implemented in those processors that software can read to get the Tj value for either the Pentium® 4 processor, Intel® Xeon® processors or Intel® Core™2 processors.

In all implementations the IA21_THERM_STATUS[22:16] value is relative to PROCHOT assertion and not an absolute temperature.

All,
Thank you for your patience. Note that the information in the post immediately before this one came from Intel, specifically from one of our internal contacts for the processor documentation, and is what we have been working with our friends on the hardware design side of Intel to get for you.
To sum up and hopefully clear some of the confusion, as there were different processor families mentioned in this long thread:
Use of bit 30 in MSR 0EEh is *not* valid for desktop, workstation or server processors based on the Intel(R) Core(TM) microarchitecture. However, for mobile processors, this assumption *is* valid.
Intel does not have any MSR that exposes the trip point for the TCC in the Core microarchitecture. Intel is not protecting an MSR that exposes the trip temperature.
Please refer back to MAD\fwildgru's post above for additional details about temperature measurement.
Also, please note that the original request to publish details about the IA32_TEMPERATURE_TARGET MSR within the SDM is with the document owners and is under review.
Any ISVs who need to access confidential documentation under NDA, but do not yet have an Intel representative, are welcome to contact us by email if you need help determining eligibility or getting in touch with a rep.
Finally, thank you all for your feedback. We have been and will continue to be in touch with several of you individually regarding suggestions you've posted here.
As we believe the technical questions previously unanswered on this topic have now been addressed by our expert contacts, we are closing this thread.
==
Lexi S.
Intel(R) Software Network Support
http://www.intel.com/software
http://softwarecommunity.intel.com/i...howThread.aspx
03-11-2007, 09:53 AM
jagatucci

Ok, to cut through all the crap...

So, should I rely on SpeedFan's reported CPU temps and completely ignore readings from the Core such as are reported in TAT, CoreTemp, and, also, SpeedFan (it's the only program I know of that reports all three). Either way, it seems we're in agreement that CPU temp is read off the top of the IHS and core temps are read from a diode within the chip itself, right. So, back to my original question. Logic tells me the temp read from the IHS should be lower than the temps read from the core. So, why is SpeedFan showing a higher CPU temp than it does temps for both the cores? Any thoughts that don't involve ambiguous suggestions that there's no way to gauge temps anymore would be much appreciated :) .
03-11-2007, 10:29 AM
GGuyZ

bing - Tj is supposed to be the junction point between the die and the PCB. Is there any textual explanation that comes with this picture to clear this up, as it is not clear from this picture.

kwalker - C2D desktop processors are also designed to have a 85C Tjunction temperature. The post you quoted in here states that there is no such information in the MSRs. This sounds a bit odd since it is basically the same architecture, so it only makes sense that there is a Tjmax value. In addition, Quad cores have a Tjmax of 100C, which also leads me to believe this value does exist.

In addition, Intel has implemented a DTS in each core on the C2D/Q desktop processors. This DTS is only handy when used with the Tjmax value(the reading in TAT/Core temp is actually -> Tjmax-DTS=CoreTemp).

Regarding bios/speedfan/other software readings, they are derived from the thermal diode. You should really prefer TAT/CoreTemp readings instead of the diode reading. While the DTS have an A/D convertor on die, the thermal diode sends an analog electrical signal to the sensor in the motherboard. This can lead to mistakes in the temp reading.
03-11-2007, 10:44 AM
jagatucci

Thanks

Thanks for your direct answer GGuyZ. That definitely helps clarify things a bit.
03-11-2007, 06:51 PM
kwalker

Quote:

Originally Posted by GGuyZ

bing - Tj is supposed to be the junction point between the die and the PCB. Is there any textual explanation that comes with this picture to clear this up, as it is not clear from this picture.

kwalker - C2D desktop processors are also designed to have a 85C Tjunction temperature. The post you quoted in here states that there is no such information in the MSRs. This sounds a bit odd since it is basically the same architecture, so it only makes sense that there is a Tjmax value. In addition, Quad cores have a Tjmax of 100C, which also leads me to believe this value does exist.

In addition, Intel has implemented a DTS in each core on the C2D/Q desktop processors. This DTS is only handy when used with the Tjmax value(the reading in TAT/Core temp is actually -> Tjmax-DTS=CoreTemp).

The posts I quoted were from the Intel developer’s forum and I supplied the link.
(Read it from the beginning)
The MSR (model specific registers) are different between each platform and have a specific function.
TAT was designed to read mobile platforms
In the core 2 architecture the DTS gets its reference from the thermal diode and is used for thermal management and fan control.
The thermal diode is actuate just not as responsive in updating thermal readings as the DTS.
Intel states that eventually the DTS will replace the thermal diode but both are enabled in current processors.
I will not discredit the other software for core temperatures I think they are ingenious but I believe they are inaccurately reporting temperatures due to the design and function of the DTS sensors on die in the Core2 architecture.
03-21-2007, 08:26 AM
GGuyZ

I apologize but I only now had the time to review this.

Quote:

Next you have to assume that the Tjunction is 100 degrees Celsius and if bit 30 of MSR 0xEE is set then it is 85 degrees Celsius. At least that is what I have found by analyzing Linux Coretemp driver. After you have correct Tjunction, reading the DTS is simple.

Here is a quote for one of the replies in that thread. Both the author of the coretemp.c driver and the guy I quoted have used reverse engineering to reach this assumption(that you can locate the TjMAX value which is either 85c or 100c). While it might be incorrect, I wonder how it has proved to be correct in so many cases and tests? Oddly enough, no one has never objected the assumption that the TjMax is either 85c or 100c. In addition, as mentioned in the quote they are verifying this data according to a certain bit in a specific register. How did they get this logic correct in so many cases if this assumption is incorrect?

EDIT: A VERY important note - It seems that the DTS delta temperature is calculated from the PROCHOT# temp(TCC Activation temp). Maybe the right way to calculate the temperature would just be to supply the DTS value(which is negative), and to know that when it reaches 0 - the CPU will start throttling.
The problem in this case is that PROCHOT# may differ from one CPU to another and it will make it impossible to keep an appropriate track on CPU temps that way. Is there a way to read the PROCHOT# value in each CPU? To my understading this is impossible.

A nice test to see if this is correct would be to see if indeed several tested processors start throttling at 85C. If I remember correctly this is indeed the case. That would mean that while the temperature isn't really 85C(since it is related to PROCHOT#), it does give some kind of indication on the temps. If the PROCHOT# temperature is higher on one CPU, then that probably means that it is somewhat more durable than the other one with a lower PROCHOT# temperature.

Any programmers in here dealing with this situation - it would be nice if you would jump into this discussion so we can try to finally reach a sensible conclusion.
03-21-2007, 09:22 AM
fgw
Quote:

Originally Posted by GGuyZ

I apologize but I only now had the time to review this.

Here is a quote for one of the replies in that thread. Both the author of the coretemp.c driver and the guy I quoted have used reverse engineering to reach this assumption(that you can locate the TjMAX value which is either 85c or 100c). While it might be incorrect, I wonder how it has proved to be correct in so many cases and tests? Oddly enough, no one has never objected the assumption that the TjMax is either 85c or 100c. In addition, as mentioned in the quote they are verifying this data according to a certain bit in a specific register. How did they get this logic correct in so many cases if this assumption is incorrect?

EDIT: A VERY important note - It seems that the DTS delta temperature is calculated from the PROCHOT# temp(shutdown temp). Maybe the right way to calculate the temperature would just be to supply the DTS value(which is negative), and to know that when it reaches 0 - the CPU will shut down.

The problem in this case is that PROCHOT# may differ from one CPU to another and it will make it impossible to keep an appropriate track on CPU temps that way. Is there a way to read the PROCHOT# value in each CPU? To my understading this is impossible.

Now that I think about it, this assumption is actually impossible. If this was indeed correct, then whenever the CPU temp reaches 85C(or 100C in C2Q) we would have encountered CPU shutdown. This is obviously ridiculous.

Any programmers in here dealing with this situation, it would be nice if you would jump into this discussion so we can try to finally reach a sensible conclusion

you are almost there! to make this even more complicated, intel introduced two different thermalpoints:
- PROCHOT# signals, TCC thermal control circuit activation => aka throttling
- THERMTRIP# thats the point, where the processor signals to the bios to shutdown the system
you are right, DTS reports a negative value which in fact is the current temperature delta to PROCHOT# (TCC activation)

both temperature values (PROCHOT# and THERMTRIP#) are calibrated during manufacturing and set by burning some bridges directly on the die. thus, this values can't be changed afterwards but what hurts even more, can't read by software. additionally, this temperatures differs from die to die.
some steppings of the mobile c2d processors indicate this temp to be approximately 85 or 100 via a single bit in the EXT_CONFIG register (msr 0EEh) but desktop, workstation and server processors don't. (this statement is from a forum at intel and from an intel representative)

you ask: "How did they get this logic correct in so many cases if this assumption is incorrect?" well, in the past in most cases the programs used accidentally the correct value either 85c or 100c although this was not correct either. it could have been 83c or even 88c - nobody knows!

the best solution, as i assume, would be the one you already mentioned: use plain dts readings!
let's get rid of all this hype about absolute temperatures and focus just on plain DTS readings. i personally prefer to know the degrees i'm away from THERMTRIP# instead a 'virtual' temperature that might be correct or some degrees off nobody knows how far off!

if i got the feature list correctly, coretemp will show this value in the current release. unfortunately there is another bug within coretemp 0.95, so i'm not able to verify this. in the meantime, you can calculate DTS back by yourself: DTS = Tjunction - Tcore (coretemp)
03-21-2007, 10:26 AM
GGuyZ

fgw, I appreciate the reply. However, even before you replied I've edited my message. I confused PROCHOT# with THERMTRIP# for a moment. I immediately corrected myself.

This is what happens when you write long messages from work. But in any case, I believe we now hold the same opinion, because what I've written matches your response almost completely.

From now on I am going to recommend people to not look at the temperature as an absolute one, but as a relative one to the pseudo TjMax. I.E: 60c in a C2D is 25c before the THERMTRIP#, while 60c in C2Q is 40C before that.
03-21-2007, 11:45 AM
zbomb5610

i was wondering if taking one processor and swapping it b/t two computers would read 2 different temps for that exact same cpu if all vcore settings, etc are the same.

If one computer has a ds3 and the other a p5b-deluxe, would just the mobo change alone make tat or any other program to read the temp a few degrees off from each other?
03-21-2007, 12:32 PM
aicjofs

Quote:

Originally Posted by zbomb5610

i was wondering if taking one processor and swapping it b/t two computers would read 2 different temps for that exact same cpu if all vcore settings, etc are the same.

If one computer has a ds3 and the other a p5b-deluxe, would just the mobo change alone make tat or any other program to read the temp a few degrees off from each other?

In theory, all variables held constant, the temps should be the same using the DTS. In the real world your TIM application, heatsink mounting can easily make a few degree change not attributed to temp monitoring.

Quote:

Regarding bios/speedfan/other software readings, they are derived from the thermal diode.

This statement is too vague, I agree they can and do read thermal diode, but that sentence is too broad as they also can read DTS.

Last speedfan I used attempts to display DTS and thermal diode and has for awhile. Exactly the same reading for "core" in speedfan as CoreTemp on an A64 but noticeable off on my C2. So I can see your point here for a C2.
03-21-2007, 01:26 PM
GGuyZ

This sentence is not vague at all. Until recently it was very true. However, since reading the information off the DTS is so simple, most programs(including everest and as I've heard speedfan too) can now read the information from the DTS.
03-21-2007, 01:35 PM
aicjofs

I think MBM5 with plugin works too.