Coretemp seems to be off quite a bit

Tue Oct 7 17:51:26 UTC 2008

On Tue, Oct 07, 2008 at 06:33:15PM +0100, Frank Shute wrote:
> On Tue, Oct 07, 2008 at 06:28:32AM -0700, Jeremy Chadwick wrote:
> >
> > On Tue, Oct 07, 2008 at 02:25:17PM +0100, Frank Shute wrote:
> > > On Mon, Oct 06, 2008 at 09:39:40AM -0500, Kirk Strauser wrote:
> > > >
> > > > I have a Gigabyte motherboard with an Intel ICH-9 chipset, and a  
> > > > 3.0GHz Core 2 Duo (E8400).  The coretemp sysctls seem to always show  
> > > > 50C as the baseline temperature:
> > > > 
> > > > $ sysctl dev.cpu | grep temp
> > > > dev.cpu.0.temperature: 50
> > > > dev.cpu.1.temperature: 50
> > > > 
> > > > This is with a big PSU fan, a good CPU fan, a clean heatsink, and two  
> > > > case fans aimed the right direction (front fan pulling cool air in,  
> > > > rear fan pushing warm air out).  If I reboot and go into the BIOS, I  
> > > > get numbers around 42-43C.  I know it's kind of hard to compare  
> > > > directly, but the coretemp numbers are from a totally idle system with  
> > > > powerd scaling it back to 373MHz, so it should be as cool as when  
> > > > sitting idle in the BIOS screens.  When I work the system hard, like  
> > > > running "make -j4 buildworld", I see temperatures up around 63-64C,  
> > > > and I'm almost positive that's not right.
> > > > 
> > > > Any ideas why coretemp and the BIOS would show such different numbers?
> > > 
> > > To add some numbers, I've got an E6550 on a Gigabyte GA-P35-DS3L
> > > (ICH9) and I get:
> > > 
> > > $ sysctl dev.cpu | grep temp
> > > dev.cpu.0.temperature: 24
> > > dev.cpu.1.temperature: 28
> > > 
> > > Ambient room temp: 23°C
> > > 
> > > That's running powerd and the machine idle, standard heatsink/fan
> > > combo, 1x12cm case fan.
> > > 
> > > Your's might run hotter (higher clock speed? Mine: 2.33GHz) but I
> > > wouldn't expect it to run *so* much hotter.
> > > 
> > > I'd expect your numbers to be right if all the ACPI stuff is working.
> > 
> > Clarification here is needed:
> > 
> > coretemp(4) has nothing to do with ACPI.  It gets thermal statistics
> > from the processor by talking *directly* to the processor with specific
> > opcodes, the results returned in specific CPU registers.  It does not
> > rely on ACPI.
> 
> Thanks for the clarification.
> 
> What I meant was that the core temperatures are dependent on clock
> speed which is dependent on powerd which is dependent on ACPI, if I'm
> not mistaken.

I believe powerd(8) is reliant upon cpufreq(4), which is reliant upon
many different pieces (depending upon what you've enabled in your kernel
and what you've configured in loader.conf).  See the cpufreq(4) man page
for details of all the drivers/methods supported -- and yep, ACPI-based
throttling is indeed there.

> i.e: If powerd isn't working properly due to ACPI bugs then you may
> have your CPU running at full clock, hence high temps. No?

Processors/hardware are not dependent upon operating systems "calming
them down" or "telling them to idle".  I forget if I mentioned use of
HLT opcodes and what not on idling processors -- this is just an "added
bonus", as HLT will often put the processor into a "deeper sleep" than
it would if it was just sitting there doing nothing.  That's why you
might see some occasional Windows programs advertising "cool your CPU
down by running this program!!!"

Let's say his average idle temperature is 40C.  If he does not use
powerd(8), his processor temperature should probably be 40C, maybe up or
down a degree.  If he starts doing something CPU-intensive, that will
obviously increase the temperature.  But when the processor isn't doing
anything, it shouldn't have a high temperature.

Keep in mind that powerd(8) using frequency or clock throttling does not
necessarily guarantee lower/colder temperatures.  It all depends on what
cpufreq(4) module is being relied upon, and what sorts of power saving
states the CPU has in it.  In the case of Core 2 Duos, there's 4 or 5
states (C1 through C5 I believe), and I've read that there's a couple
different "severities" of some of those states.  RMClock for Windows
does an awful good job of showing you what all the states are, and you
can enable/disable them (as power-down states available) simply by
clicking check boxes.

> So one possible scenario is that powerd isn't working, although Kirk
> implies that it is.
> 
> One piece of evidence that powerd is not working properly is that it
> clocked the CPU back to 373MHz - which seems an odd-looking number to
> me.

It doesn't appear odd to me.  It greatly depends on what processor model
you have, what cpufreq(4) driver you're using, what CPU features you
have turned on or off (BIOSes sometimes can set these for you), what
your FreeBSD settings are (loader.conf specifically), and what
motherboard you're using.

Case in point: here's some from a PDSMi+ board, although I'm using
debug.cpufreq.lowest="1191" in loader.conf (I don't care to have the
system downclock beyond that):

dev.cpu.0.freq: 1191
dev.cpu.0.freq_levels: 2382/-1 2084/-1 1786/-1 1488/-1 1191/-1

It would help if we could see some of his sysctl date, specifically
these:

debug.cpufreq.*
dev.cpufreq.[0-9].*
dev.cpu.[0-9].freq
dev.cpu.[0-9].freq_levels

debug.cpufreq.verbose="1" and rebooting might help too.

But let's take a step back first.

The problem reported is that his core temperatures appear very high, and
even higher when his machine is under load.  But what are we comparing
against?  We'd need an exact duplicate machine (CPU, motherboard, and
BIOS version) to see if the temps there were identical.

For all we know, it could be the heatsink/fan is not properly mounted,
or there's too much thermal paste.  Who knows.

This is why I recommended booting Windows and using CoreTemp.  The
temperatures shown there will be correct.  If those are significantly
lower than what FreeBSD reports, then we've either got a bug in the CPU
temperature stuff in FreeBSD, or the machine really is running hotter
(in which case we can start down that trail).

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |