Which Temp Monitoring Software?

God I've tried to many temp monitoring programs but the only one I think that is giving me realistic temps is RM Clock. My E4300 is at 3.08ghz (8x385), 1.5V, stock cooling, on an ASUS P5B.

TAT gives my idle temp as 60, and load as 95, which I think is ridiculous.
Speedfan says my idle temp is 45, realistic, but a load temp of 86, which is where thermal throttling should kick in, but it doesn't, and my heatsink feels warm but not 86 warm.
Orthos gives more or less the same temps as Speedfan.
RMClock gives my idle temp as 35 and load temp as 60.

So I've heard Speedfan's temps are off by 15 degrees? The temps Speedfan lists for Core 0 and Core 1 are basically the same as the temps given by RMClock for the two cores. But the CPU temp Speedfan gives is about 15 above this. Is this the 15 degree difference people talk about? Does that mean the temps Speedfan gives for Core0 and Core1 are correct, as are the temps reported by RMClock?

Thanks for any replies.

coretemp

Coretemp gives the same readings as SpeedFan's CPU reading, not its Core0 and Core1 readings. I've found Coretemp's readings to be unrealistically high, how trustworthy is RMClock though?

coretemp .95 started crashing on me. I'm using Everest, because it monitors everything and best of all, has built in support for my G15 LCD screen, so I can have my CPU, Mobo, and GPU temps listed on it. I'm using a beta version that seems to have better support for the P35 chipset than the last official release, unless something new has come out in the past week or two.

The only 100% accurate piece of temperature information for a Core 2 Duo is provided by directly reading the on chip digital thermal sensor (DTS).



This tells you how far away you are from the throttling point and I'm pretty sure that your processor is throttling. It's very difficult to run 1.50 volts with the Intel OEM cooler and run Orthos without throttling.

Software programs that try and guess what your absolute temperature is will use one of these formulas:

reported temp = 85 - DTS
reported temp = 100 - DTS

The 85 or 100 is the maximum junction temperature of your processor. It's likely 85 but with no documentation from Intel there isn't one program that you can trust to correctly report your absolute core temperature. SpeedFan assumes 85 and at the moment I tend to believe it's right. I don't believe any of the E4300 series have a maximum junction temperature of 100 which if true, is where CoreTemp is going wrong.

Whatever your opinion of the above is doesn't matter. The DTS doesn't lie and CoreTemp 0.95 is reading this sensor correctly so use it.

So you're saying the Coretemp readings are either correct, or 15 degrees too high depending on whether the Tjunction should be 100 or 85? Coretemp also incorrectly reports my frequency as 8x432 instead of 8x385. And I haven't run Orthos overnight yet, but after 90 minutes my temp was either 80 or 65 depending on what program you look at, and it hadn't throttled. Orthos has reported my temp above 85 on several occasions, and my processor didn't throttle then either, but if it was 85, it would have right?

My opinion is that the TjMax or Tjunction temperature as CoreTemp calls it is 85C for the E4300.

I have compared my processor with a couple of E4300 processors and both of them seemed to have the exact same 85C TjMax that I do.

If this is true then the programmer of CoreTemp might have made a mistake by assuming that all E4300 cpus have a TjMax of 100C. I have read a lot of Intel documentation and I have found nothing in there to support this assumption for desktop Core 2 Duo processors.

The most reliable program for reporting MHz is CPUz 1.40. Unfortunately it misreports the core voltage when you go higher than about 1.425 volts.

When I last tried RMClock I found that it was averaging the DTS data. I believe it takes a sample every second and then displays the average of the last 5 samples. I don't know if you can turn off this averaging feature but I do know that you can not directly compare an averaged value to the real time value that CoreTemp is using.

When testing TAT I found that it does not consistently track the on chip DTS. Some days it is close and some days it is off by a couple of degrees. TAT may also be assuming the wrong TjMax because it was not written for the desktop Intel Core 2 Duo processors. It is a laptop baking application designed for mobile Core processors and has never been updated.

The only temperature sensor fully documented by Intel is the DTS. CoreTemp is the only program that lets you read it by setting it like I showed above.

The Intel documentation says that when the DTS drops down to zero your processor will be throttling. When I got down to DTS=2, TAT changed from green to red and reports Thermal Monitor Active. When this happened the multiplier would briefly cycle from 8X to 6X to lower the MHz which helps control the temperature.

If you can back your overclock off a little and lower your core voltage to 1.40 volts while running Orthos then maybe we could compare absolute temperatures. Include your room temperature and the MHz you're running at. It might not prove anything but it might give you an idea that an 85C TjMax for your processor is possible.

The temperature utility in RMClock was once giving me numbers after the decimal point like 54.2C or 55.6C, etc. but I went and tried version 2.25 and it isn't doing that.

I brought up how to check temperature monitoring software before but some of it might have got lost when [H]ard dumped a week or two of posts so we'll check RMClock for any problems.

I use CrystalCPUID to read the on chip model specific register ( MSR ) that contains the raw DTS information. The 7 bits of temperature data are located in bits [22..16] of MSR 0x19C in all Core processors and even in the later P4 processors but I haven't tested that.

Here's my E6400 ( 3600 MHz 1.504 volts ) at idle in a 22C room with the Tuniq Tower fan at its lowest speed of 1150 rpm.



When you enter 0x19C in the MSR Number box and click on RDMSR ( Read MSR ) you will get the value of the DTS. In this example bits [22..16] corresponds to 36 hexadecimal which is ( 3 X 16 + 6 ) = 54 in decimal. This means at idle I am 54C degrees away from TjMax which is the Intel documented highest safe operating temperature for a C2D cpu.

If RMClock is using the DTS and calculates the absolute core temperature to be 33C then it must be assuming that my TjMax = 33C + 54C = 87C. That's certainly possible but now let's check it again at full Orthos load.



At 3600 MHz and 1.480 volts it is happily running Orthos within 18C of TjMax which is better than it usually does. I usually have to increase the fan speed a little to maintain Orthos stability here so I guess it must be breaking in at 3600 MHz after all this torture!

RMClock reports a core temperature of 63C so now it must be assuming that TjMax = 63C + 18C = 81C.

The maximum junction temperature of your processor ( TjMax ) is a fixed value, set at the factory and doesn't change yet RMClock is using two different values depending on whether the processor is hot or cold. That's not right. I also performed this test with TAT and the calculated TjMax could change from day to day which is also impossible.

Now you can run CoreTemp 0.95 or SpeedFan 4.32 and you will see that both of these programs track the on chip digital thermal sensors exactly. CoreTemp may be guessing wrong at TjMax but it can be used to report the DTS directly. When it is set like that, it will report the temperature data in processor register 0x19C exactly.

This is the only Intel documented core temperature information for a Core 2 Duo desktop processor.

ITAT

Unclewebb that post was insane and very helpful. Should start a thread with it and get it stickied imho. Well when I'm running Coretemp (showing delta Tjunction) and RMClock at the same time the addition of the two readings tends to vary from 86-87 when idle and 82-85 when under load.

Would this indicate the Tjunction to be 85C? Are these kinds of fluctuations consequences of the rate at which the temperatures are read/calculated by each program or is RMClock just plain wrong?

I agree with Unclewebb and commend his work in investigating this, I would just put in one (long ) comment. My major problem with ANY software is we do not know how the author is doing his math. I think coretemp is doing it correctly because I too think my Tjunction is 85C but wonder about other processors and changes Intel may make in the future. Unclewebb has shown a method that I trust completely as it reads the value in the MSR and the method completely agrees with Intel documentation. What method is that you ask ?

Boring backgroud alert:

Per the Intel docs the only thing (as Unclewebb says) we can know, that is documented by Intel and available to the general public, is the value in the software register (MSR) that holds the "distance in deg C away from the processor asserting a PROCHOT# interrupt". (Unclewebs bold "running without a heatsink to determine his PROCHOT# internal setting excepted ) This signal is typically used to tell the fans to go on full blast. There is another temp trip point, the catastrophic temp THERMTRIP#, where the CPU should/will just shut down, that is factory set and as far as I know, we don't know what it is other than it is set above the PROCHOT# temp trip, and we cant read or change THERMTRIP#.

This is supported by Intel documents:
Intel® Core™2 Duo Desktop Processor, Intel® Pentium® Dual Core Processor, and the Intel® Pentium® 4 Processor 6x1 Sequence Thermal and Mechanical Design Guidelines
– Supporting the Intel® Core™2 Duo desktop processor E6000 Δ and E4000 Δ sequences, Intel® Pentium® Dual Core Processor E2000 Δ sequence, and Intel® Pentium® 4 processor 6x1 sequence at 65 W
June 2007

http://download.intel.com/design/processor/designex/31368504.pdf

Section 4 is the good stuff

and here is (as far as I can tell, what started it all)
http://softwarecommunity.intel.com/isn/community/en-us/forums/thread/30222546.aspx

Meat:

So how do we read the MSR directly and take out any uncertainly as to what some program is doing, Here is the link to Unclewebbs example of using CrystalCPU-id to read the MSR directly.

http://www.hardforum.com/showpost.php?p=1031080147&postcount=5

and the point I am trying so badly to make is, it does not matter a flip what your core temp is (and we can not fully trust anything I know of to report it unless you do testing of your CPU like Unclewebb did, ) but if we know how many deg C until PROCHOT# and can trust it, we know something important. Really, does it matter if your cpu runs at 50C or 70C or 100C if it can stand 1000C ? What is critical is how close are you to tripping PROCHOT# and coretemp seems correct when set as Unclewebb recommends but I checked it vs a direct reading of the MSR to make sure.


haha all that and while typing it up , he did it even better.

Weenaboy said:

Would this indicate the Tjunction to be 85C?

Click to expand...

All this indicates is that RMClock is assuming your TjMax is somewhere around 85C. That's the problem. TjMax for the desktop processors is not publicly documented by Intel.

For all mobile Core processors, TjMax is documented to be exactly 100C.

When you work backwards and try to calculate what TjMax a program is using and it varies depending on the temperature of the processor or the day of the week then you know the temperature monitoring software is making some undocumented assumptions about TjMax. It is not correctly reporting the absolute core temperature of the processor based on the publicly available documentation from Intel.

Are these kinds of fluctuations consequences of the rate at which the temperatures are read/calculated by each program

Click to expand...

If you allow the temperature of your processor to stabilize at idle and at full load while testing, then the DTS read interval or Temp. Read Interval as CoreTemp calls it doesn't matter.

This is interesting. for a Celeron but

Regardless of enabling the automatic or on-demand modes, in the event of a catastrophic cooling failure, the processor automatically shuts down when the silicon has reached a temperature of approximately 125 °C. At this point the THERMTRIP# signal goes active. THERMTRIP# activation is independent of processor activity and does not generate any bus cycles. When THERMTRIP# is asserted, the processor core voltage must be shut down within the time specified in ...

Intel® Celeron® Processor 1.66 GHz/1.83 GHz
Datasheet
January 2007
http://www.intel.com/design/intarch/datashts/315876.pdf

bump...interesting read.