[lm-sensors] Discrepancy between reported readings from different

[lm-sensors] Discrepancy between reported readings from different

[Arun Raghavan]

Hi,

I'm running a core-i7 980x on ASUS Rampage III Extreme. I find that
the temperatures reported by the atk0110-acpi-0 and coretemp
interfaces to be quite different:

atk0110-acpi-0
Adapter: ACPI interface
CPU Temperature:       +56.5°C  (high = +60.0°C, crit = +65.0°C)

coretemp-isa-0000
Adapter: ISA adapter
Core 0:      +52.0°C  (high = +81.0°C, crit = +101.0°C)

coretemp-isa-0001
Adapter: ISA adapter
Core 1:      +47.0°C  (high = +81.0°C, crit = +101.0°C)

coretemp-isa-0002
Adapter: ISA adapter
Core 2:      +45.0°C  (high = +81.0°C, crit = +101.0°C)

coretemp-isa-0003
Adapter: ISA adapter
Core 8:      +50.0°C  (high = +81.0°C, crit = +101.0°C)

coretemp-isa-0004
Adapter: ISA adapter
Core 9:      +45.0°C  (high = +81.0°C, crit = +101.0°C)

coretemp-isa-0005
Adapter: ISA adapter
Core 10:     +51.0°C  (high = +81.0°C, crit = +101.0°C)


Apart from the 5 degree difference between the reported CPU
temperature from the ACPI interface and the max. reported coretemp,
the high and critical temperatures are drastically different. 65
degrees C seems to small for junction critical temperature 32nm Si.
Could you please advise as to what the differences represent. Are they
indeed very different things or do I need to calibrate the ACPI
(Winbond?) interface to be close to the coretemp readings?
thanks,
-arun

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Discrepancy between reported readings from

[Luca Tettamanti]

Hello,

On Sat, Oct 23, 2010 at 12:56 AM, Arun Raghavan <arraghav@gmail.com> wrote:
> Hi,
>
> I'm running a core-i7 980x on ASUS Rampage III Extreme. I find that
> the temperatures reported by the atk0110-acpi-0 and coretemp
> interfaces to be quite different:
>
> atk0110-acpi-0
> Adapter: ACPI interface
> CPU Temperature:       +56.5°C  (high = +60.0°C, crit = +65.0°C)
>
> coretemp-isa-0000
> Adapter: ISA adapter
> Core 0:      +52.0°C  (high = +81.0°C, crit = +101.0°C)
[cut]
> Apart from the 5 degree difference between the reported CPU
> temperature from the ACPI interface and the max. reported coretemp,
> the high and critical temperatures are drastically different. 65
> degrees C seems to small for junction critical temperature 32nm Si.
> Could you please advise as to what the differences represent. Are they
> indeed very different things or do I need to calibrate the ACPI
> (Winbond?) interface to be close to the coretemp readings?

The readings most probably come from different sources: an internal
sensor for coretemp, an external probe usually under the socket for
ATK0110 (the hwmon chip might by using PECI though). ACPI code may
also contain additional calibration code (e.g. I've seen a board that
tries to calibrate the CPU reading using the board temperature), see
also [1].
coretemp actually reads the delta between the current temperature and
TjMax (i.e. the core is X° below TjMax) not an actual absolute
temperature; the digital sensor is more accurate near TjMax and -
according to Intel[2] - the reading "deteriorates to +-10C at 50C": in
your case you should be reading the output as: you're far from the
safety limit, everything is cool (literally :D).
As for the limits: the driver just displays whatever the BIOS reports,
it might not be the actual limit (especially if it's not
configurable).

Luca
[1] http://article.gmane.org/gmane.linux.drivers.sensors/21304
[2] http://article.gmane.org/gmane.linux.kernel/998038

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Discrepancy between reported readings from

[Arun Raghavan]

Hi,

Thanks for the quick response and the links. I'm not sure I understand
exactly how to proceed or how to interpret your point about coretemp
being relative to Tjmax. I see the coretemp value increasing with
activity, implying the reading is greater the hotter it gets. If it
were a delta from Tjmax, I would expect it to decrease?
I also have thermometers probing across the heat sink and they seem to
match the coretemp readings at idle (of course, when the CPU heats up,
the package temperature is hotter than the heatsink probe detects).
Should I just trust the coretemp readings to a reasonable
approximation?

thanks!


On Sat, Oct 23, 2010 at 9:02 AM, Luca Tettamanti <kronos.it@gmail.com> wrote:
> Hello,
>
> On Sat, Oct 23, 2010 at 12:56 AM, Arun Raghavan <arraghav@gmail.com> wrote:
>> Hi,
>>
>> I'm running a core-i7 980x on ASUS Rampage III Extreme. I find that
>> the temperatures reported by the atk0110-acpi-0 and coretemp
>> interfaces to be quite different:
>>
>> atk0110-acpi-0
>> Adapter: ACPI interface
>> CPU Temperature:       +56.5°C  (high = +60.0°C, crit = +65.0°C)
>>
>> coretemp-isa-0000
>> Adapter: ISA adapter
>> Core 0:      +52.0°C  (high = +81.0°C, crit = +101.0°C)
> [cut]
>> Apart from the 5 degree difference between the reported CPU
>> temperature from the ACPI interface and the max. reported coretemp,
>> the high and critical temperatures are drastically different. 65
>> degrees C seems to small for junction critical temperature 32nm Si.
>> Could you please advise as to what the differences represent. Are they
>> indeed very different things or do I need to calibrate the ACPI
>> (Winbond?) interface to be close to the coretemp readings?
>
> The readings most probably come from different sources: an internal
> sensor for coretemp, an external probe usually under the socket for
> ATK0110 (the hwmon chip might by using PECI though). ACPI code may
> also contain additional calibration code (e.g. I've seen a board that
> tries to calibrate the CPU reading using the board temperature), see
> also [1].
> coretemp actually reads the delta between the current temperature and
> TjMax (i.e. the core is X° below TjMax) not an actual absolute
> temperature; the digital sensor is more accurate near TjMax and -
> according to Intel[2] - the reading "deteriorates to +-10C at 50C": in
> your case you should be reading the output as: you're far from the
> safety limit, everything is cool (literally :D).
> As for the limits: the driver just displays whatever the BIOS reports,
> it might not be the actual limit (especially if it's not
> configurable).
>
> Luca
> [1] http://article.gmane.org/gmane.linux.drivers.sensors/21304
> [2] http://article.gmane.org/gmane.linux.kernel/998038
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Discrepancy between reported readings from

[Luca Tettamanti]

On Sun, Oct 24, 2010 at 11:27 PM, Arun Raghavan <arraghav@gmail.com> wrote:
> Hi,
>
> Thanks for the quick response and the links. I'm not sure I understand
> exactly how to proceed or how to interpret your point about coretemp
> being relative to Tjmax. I see the coretemp value increasing with
> activity, implying the reading is greater the hotter it gets. If it
> were a delta from Tjmax, I would expect it to decrease?

Tjmax is the upper limit at which the CPU forces the throttling
(AFAIK). The exact value varies between CPUs, in you case it should be
101°C; the DTS reports a negative value (or rather a positive margin)
relative to TjMax, the driver converts it to an absolute temperature.
Tabs = TjMax - Tdts

> I also have thermometers probing across the heat sink and they seem to
> match the coretemp readings at idle (of course, when the CPU heats up,
> the package temperature is hotter than the heatsink probe detects).
> Should I just trust the coretemp readings to a reasonable
> approximation?

I should be :) For some desktop CPU the exact value for TjMax is not
known and is assumed to be 100°C; in this case the driver emits a
warning in the log.

Luca

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Discrepancy between reported readings from

[Arun Raghavan]

Thanks again for the prompt response. One more question regarding
coretemp: any idea how I can probe the sensor in my own source code?
I'm hoping to be able to probe a few times a second, while the
lm-sensors usage guide says max. probing frequency should be at most
0.3-0.5 Hz. I'm trying to measure thermal response and hence
transients. Temperature rises rather too rapidly for this once every
2-3 seconds restriction; there's no intermediate reading between idle
temperature (~28C) and loaded (~55C). Even when I overclock to
deliberately induce more dissipation, I don't get an intermediate
reading between the same base temperature and 70C!
Please let me know if the 2-3s resolution is a limitation of the
sensors API or the kernel module itself. Any tips on how I might be
able to measure with greater frequency (apart from hooking up an
external probe and thermometer)?

thanks!

On Sun, Oct 24, 2010 at 5:42 PM, Luca Tettamanti <kronos.it@gmail.com> wrote:
> On Sun, Oct 24, 2010 at 11:27 PM, Arun Raghavan <arraghav@gmail.com> wrote:
>> Hi,
>>
>> Thanks for the quick response and the links. I'm not sure I understand
>> exactly how to proceed or how to interpret your point about coretemp
>> being relative to Tjmax. I see the coretemp value increasing with
>> activity, implying the reading is greater the hotter it gets. If it
>> were a delta from Tjmax, I would expect it to decrease?
>
> Tjmax is the upper limit at which the CPU forces the throttling
> (AFAIK). The exact value varies between CPUs, in you case it should be
> 101°C; the DTS reports a negative value (or rather a positive margin)
> relative to TjMax, the driver converts it to an absolute temperature.
> Tabs = TjMax - Tdts
>
>> I also have thermometers probing across the heat sink and they seem to
>> match the coretemp readings at idle (of course, when the CPU heats up,
>> the package temperature is hotter than the heatsink probe detects).
>> Should I just trust the coretemp readings to a reasonable
>> approximation?
>
> I should be :) For some desktop CPU the exact value for TjMax is not
> known and is assumed to be 100°C; in this case the driver emits a
> warning in the log.
>
> Luca
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Discrepancy between reported readings from

[Guenter Roeck]

On Sun, Oct 24, 2010 at 09:40:38PM -0400, Arun Raghavan wrote:
> Thanks again for the prompt response. One more question regarding
> coretemp: any idea how I can probe the sensor in my own source code?
> I'm hoping to be able to probe a few times a second, while the
> lm-sensors usage guide says max. probing frequency should be at most
> 0.3-0.5 Hz. I'm trying to measure thermal response and hence
> transients. Temperature rises rather too rapidly for this once every
> 2-3 seconds restriction; there's no intermediate reading between idle
> temperature (~28C) and loaded (~55C). Even when I overclock to
> deliberately induce more dissipation, I don't get an intermediate
> reading between the same base temperature and 70C!
> Please let me know if the 2-3s resolution is a limitation of the
> sensors API or the kernel module itself. Any tips on how I might be
> able to measure with greater frequency (apart from hooking up an
> external probe and thermometer)?
> 
Please don't top-post.

Technically, you can keep reading the sysfs attribute file in a continuous 
loop without delay. However, the coretemp driver updates its readings only
once per second.  You can poll faster, of course, but it won't help much.

Just wondering - did you _try_ probing it faster than the guide says ?
If no, why not ? After all, it is a usage guide, not a law.

Thanks,
Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Discrepancy between reported readings from

[Jean Delvare]

Hi Arun,

On Sun, 24 Oct 2010 21:40:38 -0400, Arun Raghavan wrote:
> Thanks again for the prompt response. One more question regarding
> coretemp: any idea how I can probe the sensor in my own source code?
> I'm hoping to be able to probe a few times a second, while the
> lm-sensors usage guide says max. probing frequency should be at most
> 0.3-0.5 Hz.

Out of curiosity, which "usage guide" are you referring to?

> I'm trying to measure thermal response and hence
> transients. Temperature rises rather too rapidly for this once every
> 2-3 seconds restriction; there's no intermediate reading between idle
> temperature (~28C) and loaded (~55C). Even when I overclock to
> deliberately induce more dissipation, I don't get an intermediate
> reading between the same base temperature and 70C!

There's no reason why overclocking would help. Overclocking will
generate more heat, but the time it takes to generate it won't change.

> Please let me know if the 2-3s resolution is a limitation of the
> sensors API or the kernel module itself. Any tips on how I might be
> able to measure with greater frequency (apart from hooking up an
> external probe and thermometer)?

There's no limitation at the sensors API level. Each kernel driver has
its own cache lifetime depending on various things, including the
number of registers to read, how fast or slow register access is, and
the driver design.

In the case of the coretemp driver, the 1 second lifetime is pretty
arbitrary, as there are only a few registers to read (one per core) and
register access is very fast (CPU MSRs). Fenghua, Guenter, do you think
it would make sense to shorten the cache lifetime to 0.5 or even 0.25
second?

Arun, back to your immediate issue, you have two options, either
rebuild the coretemp driver with a shorter cache lifetime (replace HZ
with HZ/10 in function coretemp_update_device) or access the MSR
yourself from user-space (but then you lose all the power of
libsensors.)

-- 
Jean Delvare
http://khali.linux-fr.org/wishlist.html

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Discrepancy between reported readings from

[Guenter Roeck]

On Mon, Oct 25, 2010 at 03:16:02AM -0400, Jean Delvare wrote:
> Hi Arun,
> 
> On Sun, 24 Oct 2010 21:40:38 -0400, Arun Raghavan wrote:
> > Thanks again for the prompt response. One more question regarding
> > coretemp: any idea how I can probe the sensor in my own source code?
> > I'm hoping to be able to probe a few times a second, while the
> > lm-sensors usage guide says max. probing frequency should be at most
> > 0.3-0.5 Hz.
> 
> Out of curiosity, which "usage guide" are you referring to?
> 
> > I'm trying to measure thermal response and hence
> > transients. Temperature rises rather too rapidly for this once every
> > 2-3 seconds restriction; there's no intermediate reading between idle
> > temperature (~28C) and loaded (~55C). Even when I overclock to
> > deliberately induce more dissipation, I don't get an intermediate
> > reading between the same base temperature and 70C!
> 
> There's no reason why overclocking would help. Overclocking will
> generate more heat, but the time it takes to generate it won't change.
> 
> > Please let me know if the 2-3s resolution is a limitation of the
> > sensors API or the kernel module itself. Any tips on how I might be
> > able to measure with greater frequency (apart from hooking up an
> > external probe and thermometer)?
> 
> There's no limitation at the sensors API level. Each kernel driver has
> its own cache lifetime depending on various things, including the
> number of registers to read, how fast or slow register access is, and
> the driver design.
> 
> In the case of the coretemp driver, the 1 second lifetime is pretty
> arbitrary, as there are only a few registers to read (one per core) and
> register access is very fast (CPU MSRs). Fenghua, Guenter, do you think
> it would make sense to shorten the cache lifetime to 0.5 or even 0.25
> second?
> 
Might be even less - eg 100ms or even 50ms - if the temperature can rise
significantly in a very short period of time, as suggested above.
Plus of course if the sensor updates its readings that fast.

Guenter

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Discrepancy between reported readings from

[Arun Raghavan]

Hi Jean,

> On Sun, 24 Oct 2010 21:40:38 -0400, Arun Raghavan wrote:
>> Thanks again for the prompt response. One more question regarding
>> coretemp: any idea how I can probe the sensor in my own source code?
>> I'm hoping to be able to probe a few times a second, while the
>> lm-sensors usage guide says max. probing frequency should be at most
>> 0.3-0.5 Hz.
>
> Out of curiosity, which "usage guide" are you referring to?
>
'Usage guide' was probably misleading, I meant the FAQ:
http://www.lm-sensors.org/wiki/FAQ/Chapter1

[snip]
> There's no reason why overclocking would help. Overclocking will
> generate more heat, but the time it takes to generate it won't change.
>
Since the maximum temperature was higher, I was hoping to see some
intermediate reading
between idle and fully-loaded temperatures.

[snip]
> Arun, back to your immediate issue, you have two options, either
> rebuild the coretemp driver with a shorter cache lifetime (replace HZ
> with HZ/10 in function coretemp_update_device) or access the MSR
> yourself from user-space (but then you lose all the power of
> libsensors.)
>
Thanks for the suggestion, I will try it. Is it known how frequently the sensors
actually update the readings?

thanks,
-arun

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Discrepancy between reported readings from

[Jean Delvare]

On Tue, 26 Oct 2010 09:43:47 -0400, Arun Raghavan wrote:
> > Arun, back to your immediate issue, you have two options, either
> > rebuild the coretemp driver with a shorter cache lifetime (replace HZ
> > with HZ/10 in function coretemp_update_device) or access the MSR
> > yourself from user-space (but then you lose all the power of
> > libsensors.)
>
> Thanks for the suggestion, I will try it. Is it known how frequently the sensors
> actually update the readings?

No, I have no idea, sorry. You'll have to either dig into the Intel
documentation (but I am not sure if they actually document this detail)
or get in touch with someone at Intel.

But it's certainly updated much more frequently than the driver
currently allows.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Discrepancy between reported readings from

[Jean Delvare]

On Tue, 26 Oct 2010 09:43:47 -0400, Arun Raghavan wrote:
> > On Sun, 24 Oct 2010 21:40:38 -0400, Arun Raghavan wrote:
> [snip]
> > There's no reason why overclocking would help. Overclocking will
> > generate more heat, but the time it takes to generate it won't change.
> >
> Since the maximum temperature was higher, I was hoping to see some
> intermediate reading
> between idle and fully-loaded temperatures.
> 
> [snip]
> > Arun, back to your immediate issue, you have two options, either
> > rebuild the coretemp driver with a shorter cache lifetime (replace HZ
> > with HZ/10 in function coretemp_update_device) or access the MSR
> > yourself from user-space (but then you lose all the power of
> > libsensors.)
> >
> Thanks for the suggestion, I will try it. Is it known how frequently the sensors
> actually update the readings?

Arun, are there any results from your tests? I would like to lower the
cache lifetime in the coretemp driver and am looking for real-world
numbers to decide what would be a reasonable duration. 

I could do some experiments on my two coretemp machines, but if you
already have figures available, I'm interested :)

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Discrepancy between reported readings from

[Jean Delvare]

Hi Arun,

Please keep the list Cc'd.

On Sat, 13 Nov 2010 18:45:16 -0500, Arun Raghavan wrote:
> I recompiled with HZ/10 and I still can't see any resolution when the
> temperature begins to rise - here are two consecutive readings 100ms
> apart:
> 
> 0: +29.0°C 1: +24.0°C 2: +24.0°C 8: +27.0°C 9: +19.0°C 10: +26.0°C
> <Begin execution>
> 0: +35.0°C 1: +29.0°C 2: +27.0°C 8: +35.0°C 9: +30.0°C 10: +36.0°C
> 
> Any further suggestions?

You could try HZ/100, just for testing. What's your test protocol, BTW?
I'll try doing my own tests.

Now it is entirely possible that the sensor itself (or the MSR
interface thereto) has latency/caching. Maybe the information is
available in Intel's documents (but I really don't have the time to
look for it) or maybe you have to ask Intel about the technical details
- not sure if they want to share on this though.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Discrepancy between reported readings from

[Arun Raghavan]

Jean,
>
> On Sat, 13 Nov 2010 18:45:16 -0500, Arun Raghavan wrote:
>> I recompiled with HZ/10 and I still can't see any resolution when the
>> temperature begins to rise - here are two consecutive readings 100ms
>> apart:
>>
>> 0: +29.0°C 1: +24.0°C 2: +24.0°C 8: +27.0°C 9: +19.0°C 10: +26.0°C
>> <Begin execution>
>> 0: +35.0°C 1: +29.0°C 2: +27.0°C 8: +35.0°C 9: +30.0°C 10: +36.0°C
>>
>> Any further suggestions?
>
> You could try HZ/100, just for testing. What's your test protocol, BTW?
> I'll try doing my own tests.
>
HZ/100 didn't give me any differences either. I'm going to try reading
the MSR myself and see whether there's intermediate updates.
My test programs are from the cpuburn suite. I run 6 of them (one each
pinned to a thread). A script monitors the temperature continually (in
fixed intervals). Initially the CPUs are kept idle for 2 minutes, then
the 6 threads are kicked-off to run for 5 minutes and then the threads
are killed off with the temperature being monitored for a further 2
minutes.
The fixed interval was 1s in the graph I sent you earlier and brought
down to 10ms and 1ms with HZ/10 and HZ/100 versions.
Please let me know what your testing protocol is too.

thanks,
-arun

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] Discrepancy between reported readings from

[Arun Raghavan]

Hi Jean,

Any luck on this front?

thanks,
-arun

On Sun, Nov 14, 2010 at 10:51 PM, Arun Raghavan <arraghav@gmail.com> wrote:
> Jean,
>>
>> On Sat, 13 Nov 2010 18:45:16 -0500, Arun Raghavan wrote:
>>> I recompiled with HZ/10 and I still can't see any resolution when the
>>> temperature begins to rise - here are two consecutive readings 100ms
>>> apart:
>>>
>>> 0: +29.0°C 1: +24.0°C 2: +24.0°C 8: +27.0°C 9: +19.0°C 10: +26.0°C
>>> <Begin execution>
>>> 0: +35.0°C 1: +29.0°C 2: +27.0°C 8: +35.0°C 9: +30.0°C 10: +36.0°C
>>>
>>> Any further suggestions?
>>
>> You could try HZ/100, just for testing. What's your test protocol, BTW?
>> I'll try doing my own tests.
>>
> HZ/100 didn't give me any differences either. I'm going to try reading
> the MSR myself and see whether there's intermediate updates.
> My test programs are from the cpuburn suite. I run 6 of them (one each
> pinned to a thread). A script monitors the temperature continually (in
> fixed intervals). Initially the CPUs are kept idle for 2 minutes, then
> the 6 threads are kicked-off to run for 5 minutes and then the threads
> are killed off with the temperature being monitored for a further 2
> minutes.
> The fixed interval was 1s in the graph I sent you earlier and brought
> down to 10ms and 1ms with HZ/10 and HZ/100 versions.
> Please let me know what your testing protocol is too.
>
> thanks,
> -arun
>

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors