From: "John Chris Wren" <jcwren@jcwren.com>
To: <linux-kernel@vger.kernel.org>
Subject: RE: temperature standard - global config option?
Date: Fri, 8 Jun 2001 19:53:06 -0400 [thread overview]
Message-ID: <NDBBKBJHGFJMEMHPOPEGMEOOCIAA.jcwren@jcwren.com> (raw)
In-Reply-To: <20010608191600.A12143@alcove.wittsend.com>
[Snip] (Mike writes a bunch a good stuff)
> Yes, bits are free, sort of... That's why an extra decimal
> place is "ok". Keeping precision within an order of magnitude of
> accuracy is within the realm of reasonable. Running out to two decimal
> places for this particular application is just silly. If it were for
> calibrated lab equipment, fine. But not for CPU temperatures.
>
> Yes, APIs are difficult to change. But can you honestly say
> that, even if we magically get off the shelf economical
> temperature sensors
> that are two orders of magnitude more accurate (without need of constant
> tracible recalibration - these things DO drift), that this level of
> precision would have any real meaning at all? I would expect the
> CPU temperature to vary by a few hundreths of a degree just by how
> many people were sweating in the cube next to me.
>
[snip]
>
> Now... That I can agree with and it would make absolute sense.
> Especially if we were discussing lab grade or scientific grade measure
> equipment and measurements. In fact, that would be a requirement for
> any validity to be attached to measurements of that level of precision.
> But that's not what we are talking about here, is it? We're not talking
> about a lab grade instrumentation API here, are we? If we are, then
> everything changes.
>
> Mike
As someone who has been intimately involved in temperature measurement of
electronics, Mike has pretty much thoroughly addressed the issue. Allow me
to add this: You can go buy 12 "calibrated" temperature sensors
(commercial, not lab quality), and you will get 12 different temperatures.
When sampling the sensor (usually a thermocouple) in a motherboard, you have
at best 1% resistors being used in the surrounding support components,
+20%/-10% capacitors, A/Ds with +-1 LSB resolution, and worst of all, a
coupling to the CPU that is about as bad as it can get. You've got an epoxy
housing of an inconsistent shape in contact with ceramic. The actual
contact point is miniscule. There's no thermal paste, and often, I've seen
the sensors not quite raised high enough to contact the chip (you should be
able to rack a business card across the empty socket and feel a slight
"bump" as you touch the sensor. If not, you need to bend it up slightly, to
give better physical contact to the CPU).
But in spite of all this, you're not really measure the critical
temperature, which is junction tempature. Yes, case tempature has *some*
correlation, but it's not ratiometric. It can be affected by the mounting
of the motherboard (believe it or not, you can see over 1C different in
temperature between a vertical and horizontally mounted motherboard just
because of convection out from under the socket.
Yea, we would all love to truly know the CPU tempature down to a fraction of
a degree. But it's useless information. Kinda of like knowing your fan
speed to less than 100 RPM. Voltages fluctuations of .1 volts can cause a
100+ RPM change in the fan speed. All you really need to know that it's
turning a lot less than when it first was. But I digress.
Temperature measurement is an art. It requires having good sensors, good
conversion electronics, and good mechanical coupling (if you really doubt
this, look at the networks required to properly compensate any standard JK
thermocouple). On top of ALL this mess, you have values being passed back
from the hardware that are improperly converted. Ever wonder why the BIOS
never exactly matches what you see from the 'sensors' program? It's because
the adjustment factors in the config file are a best guess.
For the record, in the course of a normal day, I see my temperatures
fluctuate from 48C with the house A/C set to 73, to 56C when I open the
doors, and let it get up to 76 in the house. That's 8C (14.4F) over a 3F
change in ambient.
--John
next prev parent reply other threads:[~2001-06-08 23:53 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-06 12:27 David N. Welton
2001-06-06 13:50 ` Pavel Machek
2001-06-06 16:06 ` Chris Boot
2001-06-06 16:16 ` Peter Svensson
2001-06-06 16:58 ` Bill Pringlemeir
2001-06-06 20:47 ` H. Peter Anvin
2001-06-06 21:40 ` Kipp Cannon
2001-06-06 23:02 ` Maciej Zenczykowski
2001-06-06 23:27 ` David Flynn
2001-06-08 20:04 ` Pavel Machek
[not found] ` <9fm4sc@cesium.transmeta.com>
2001-06-08 20:06 ` Pavel Machek
2001-06-06 19:32 ` Matthias Urlichs
2001-06-06 21:45 ` es1371 compile issue in 2.4.5-ac9 Alan Olsen
2001-06-07 15:14 ` Keith Owens
2001-06-07 18:27 ` Alan Olsen
2001-06-06 19:44 ` temperature standard - global config option? José Luis Domingo López
2001-06-07 3:50 ` watermodem
2001-06-06 20:42 ` Pavel Machek
2001-06-06 21:52 ` J . A . Magallon
2001-06-07 10:05 ` Philips
2001-06-07 12:20 ` L. K.
2001-06-07 16:44 ` David Rees
2001-06-07 21:37 ` Chris Boot
2001-06-08 0:03 ` Albert D. Cahalan
2001-06-08 0:54 ` Michael H. Warfield
2001-06-07 21:02 ` Albert D. Cahalan
2001-06-07 21:23 ` L. K.
2001-06-07 21:30 ` mirabilos {Thorsten Glaser}
2001-06-08 1:21 ` Michael H. Warfield
2001-06-08 11:30 ` Thomas Speck
2001-06-08 17:33 ` Chris Boot
2001-06-08 18:05 ` Michael H. Warfield
2001-06-08 18:43 ` J . A . Magallon
2001-06-08 18:56 ` Michael H. Warfield
2001-06-08 19:00 ` J . A . Magallon
2001-06-08 21:16 ` Albert D. Cahalan
2001-06-08 21:22 ` L. K.
2001-06-08 21:38 ` Albert D. Cahalan
2001-06-08 21:28 ` Chris Boot
2001-06-09 7:55 ` H. Peter Anvin
2001-06-21 11:18 ` Jonathan Morton
2001-06-21 15:39 ` Kurt Roeckx
2001-06-08 23:16 ` Michael H. Warfield
2001-06-08 23:53 ` John Chris Wren [this message]
2001-06-09 3:52 ` Albert D. Cahalan
2001-06-09 7:58 ` H. Peter Anvin
2001-06-09 9:17 ` James Sutherland
2001-06-09 15:06 ` Charles Cazabon
2001-06-09 0:13 ` Bill Pringlemeir
2001-06-09 10:11 ` L. K.
2001-06-09 10:20 ` Steffen Persvold
2001-06-09 17:21 ` Chris Boot
2001-06-09 5:45 ` Albert D. Cahalan
2001-06-09 7:57 ` H. Peter Anvin
2001-06-09 8:00 ` Albert D. Cahalan
2001-06-09 8:43 ` H. Peter Anvin
2001-06-21 7:33 ` Kai Henningsen
2001-06-08 6:48 ` L. K.
2001-06-06 14:06 ` john slee
2001-06-06 19:19 ` J . A . Magallon
2001-06-06 19:01 ` Dr. Kelsey Hudson
2001-06-06 19:08 ` Alan Cox
2001-06-06 19:26 ` J . A . Magallon
2001-06-06 21:00 ` Paul Fulghum
2001-06-06 21:01 ` Harald Arnesen
2001-06-06 21:05 ` Alan Cox
2001-06-07 10:43 ` David N. Welton
2001-06-06 20:45 ` Pavel Machek
2001-06-06 21:04 ` Alan Cox
2001-06-07 22:10 Chris Adams
2001-06-08 21:33 Leif Sawyer
2001-06-08 23:50 ` Michael H. Warfield
2001-06-09 9:30 ` L. K.
2001-06-21 12:06 Randal, Phil
2001-06-21 12:56 ` Richard B. Johnson
2001-06-21 12:45 Richard J Moore
2001-06-21 16:59 ` Lauri Tischler
2001-06-21 19:14 ` Kai Henningsen
2001-06-21 20:19 ` Lauri Tischler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=NDBBKBJHGFJMEMHPOPEGMEOOCIAA.jcwren@jcwren.com \
--to=jcwren@jcwren.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®