[Official] CPU Temp Results

[jrl9851]

Awesome graph!!! So this pretty much means that it's completely safe to run at 800mhz?

[Matth3w]

Wow, good response KZI, I will change my thread later to reflect your information. Still, they are pretty accurate.

[Matth3w]

What do you guys think of these temps? Ridiculous, safe, ok, what?

[Daver]

I forced it run at 950mhz for 3 hours strait with the heat sync clocked by a pillow, temps got up to 47 deg C.

90 deg C is the limit for this chip per the OEM but the sensor is not right on the chip so hard to say exactly what it's temp was.

I posted this elsewhere but for best temps/bat life and performance

go to setcpu,
CPU governor to On Demand
Advanced>
up threshold to 70 and
power save bias to 70
reboot so it takes effect.

Just set these, eventhough I have no idea how I'm going to notice the result, I'm giving it a try lol.

[Matth3w]

Yeah, what Dave said...what does that do exactly?

[mikes]

i was under the impression that the temp sensor was not on the chip itself making monitoring the temp on chip kind of a guessing game. am i incorrect?

That is correct. Unlike current Intel desktop/laptop processors (which have an integral thermal diode sensor), the OMAP processors do not include an integral temperature sensor.

TI has not made public a datasheet for the OMAP3430 processor used in the Droid. There is a datasheet for the similar OMAP3530. It is unknown how similar the relevant specs are, but it's the best info available.

Although it gives specs for maximum junction temperature, there is no way to measure this directly. Instead, they provide a table of maximum current allowed for each of the 9 power domains on the chip, based on modeling. It is assumed that the design will be measured to ensure it stays within these guidelines.

The temp sensor on the Droid is in a separate chip, which is separated both physically and thermally from the CPU. Even if one had full design specs, and modeled the heat flow, it would be nearly impossible to determine whether the processor was exceeding it's maximum rating at any point in time.

First, in normal ambient temperatures, the processor will always be hotter than the sensor indicates, since it is a source of heat.

Second, there are 9 power domains on the processor, which complicates things since one domain may overheat (such as the CPU core), while others are fine, and the average of all is fine (the average is all that you can expect to sense externally).

Third, there is thermal mass between the processor and the temperature sensor, which slows the rise/fall times of the temperatures being sensed (e.g. the processor could be overheating for brief periods, and you would never detect it with the sensor).

Finally, it will depend on the external ambient temperature - the sensor has no way to determine the balance between internal heating and external cooling. The processor temperature could remain constant, and it will measure warmer or cooler based on the ambient temperature.

The processor specification for the maximum ambient temperature is 70C (158F), but that obviously applies only when running it within other specifications. If you're overclocking, that temperature would have to be reduced, since more cooling would be required to keep the junction temperature reasonable. Especially since the processor is covered by a RAM chip (and therefore not directly exposed to airflow), and is a heat source, it should be expected that it's perceived ambient temperature is significantly higher than the sensor's.

If the sensor were to measure 85C, the processor would be operating way beyond specification.

Finally, TI also makes it clear the expected lifetime for the processor is inversely related to both clock speed and temperature.

[KZIWarrior]

^^++ Excellent post Mike.

What do you guys think of these temps? Ridiculous, safe, ok, what?

What/were are your temps coming from? Were these temps from a battery app or from another sensor near the processor.

As we still have no idea what the board and other components on the board can handle this is all still essentially SWAGing as to any long term hazards.

It should also be noted that the design of the chip in general is relatively new and there's been little to no study of the effects of overclocking on this type of processor (this chip design is VERY different from the simpler 'multi-core' processors in our PCs that people have been overclocking for years).

[Matth3w]

I answered your questions in the op

[nyijedi]

Running at 800 MHz, I've managed to get my temp up to 45C/114F while doing heavy browsing and listening to music. The top of the back of my phone also got noticeably hotter. Are others not seeing these kind of temperatures when OC'd at 800?

Also, BB - even at 500 MHz - seemed apt to run a little hotter than stock 2.0.1. Anyone else notice this?

[deputc26]

There is no temperature sensor on the CPU. For those interested about temps this is from a conversation I had with the maker of TempMonitor and contains some VERY GOOD information about the device and temp programs:

Original question:
Okay I just researched and saw that the AK8973 (the device listed on the screen in the OP) is the compass within the phone. So then I'll mod the question as to if they is better (more precise) than the battery temp that other programs read?? Is this closer to the processor or is that just one of the sensors that the monitor reads?? Thanks again.

Answer from DustinMJ (the developer):
This is a very good question, and I'm glad you asked it

First, yes, this is not a sensor located on the actual proc itself. The sensor this app reads from is the primary 'Temperature Sensor' as identified by the android system (The app 'asks' the android system for it's temp sensor). Based on the api docs, the result is a 'composite result', however, the Droid does not appear to have this set up, so no 'default temp sensor' is returned that would allow the app to listen for 'composite results'. When this happens (which it does on Droid), the app will ask for 'all sensors' in the 'temp sensor' category (the droid then returns only one sensor) and tries to use the best option (On droid the one sensor that is returned, is the best option). I can't say for sure, but based on my research and testing, both of these temps come from the same sensor.

Before I go further I want to say that I love the curvefish battery app and have much respect for the developer, I highly recommend this as a supplement, and it's the reason my app does not have a widget.

Here's where things get interesting... there are two ways that it's possible to get *any* temperature reading on this device (well actually there's one more, and I'll touch on that at the end of my spiel), either by using the system to get real-time data, or tapping a readout file that the system stores for battery temperature. The problem with the first option is that it can take a while for the sensor to begin to return data, but once the data is returned, it is real-time data from the sensor. The problem with the second option is that the system doesn't update the file very often at all (Really, at all... I've yet to figure out the exact interval but it's slow... minutes or even halves of hours in between updates, at least on my device), however, there is no delay in reading this data.

The latest version of the TempMonitor app is a 'composite' of these two methods, that is, it shows the data stored by the system while it's waiting for real-time updates from option 1. This is nice because it gives you immediate data, but the data stored by the system could be 15 minutes old... so it's no good for OC, and really can't be trusted as 'current', wait for it to get real-time updates. The notification runs as a completely different thread (it's separate from the main app screen), so once it's on the notification bar, it receives real-time updates indefinitely. This is your most accurate temp reading. ALWAYS TRUST THE NOTIFICATION TEMP, it is always real-time and reads from the best possible sensor available.

The curvefish battery app reads the temperature that the system stores, at an interval that I'm not sure of. Remember that the temperature is stored at sporadic and lengthy intervals, so this is not the best value to trust when OC'ing. If you doubt this, prove it to yourself: Code:
Open the current market version of the TempMonitor, and if it doesn't say "Showing system data, waiting for real-time updates", close it, and open it again until it says that (this means the system is not responding good to real-time update request, this tends to happen when you visit the app screen multiple times really quickly). Look at the value shown for the system stored temperature and compare it to the curvefish readout... it may be different, but this is not because it's a different source, but because of the curvefish battery app update interval. To prove this, delete and recreate the curvefish widget on your homescreen.


SensorList (also on the market) reads only the real-time data sent by the system, this is why sometimes it says 0 for a long ass time before it finally updtes.

I'll stop blabbering there, 'cause Brent hates to read long posts , I hope this was helpful. If you see something I missed or you think is wrong, please call me on it

Great info thanks for sharing

edit: and here is what the settings my earlier post changed are about.

up-threshold- Is the %CPU useage that will cause the CPU to go to a higher frequency, the lower it is the less likely it will be for your CPU to get caught by a sudden load and lag.

power saving bias: (scale of 0 to 1000) at 1000 the CPU will almost always be the lowest it's allowed to be at, at 0 it's almost always at the highest it's allowed to be at. I've tested different settings and found 70-100 to be best.

note that even though your proc may be staying at max freq, it will not generate *too* much more heat unless an actual load is placed on it.