Comment 5 for bug 680353

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/23/2010 09:55 PM, Martin Pool wrote:

> ... or, perhaps better, just use the abstraction across various
> methods provided by libsensors? People might also want to graph hdd
> temperatures?

How does that abstraction work? Can it tell what each "tempN" above is?
If yes, any particular reason why "sensors" doesn't use it?

>> One of the concerns I have is that the output of sensors is not always
>> accurate and can be confusing, with names we have no idea what they
>> represent, like temp1, temp2, etc.
>
> I agree, though this does seem to be a problem for acpi too?

Not in our experience, the thermal zones from acpi have been correct so
far both in values and in which component is being measured.

> Another problem, across all methods, is that some sensors seem stuck
> at unreasonable values like 0 or 127C.

Yes. Unfortunately that coincides with the maximum possible value for an
8 bit value, right?

> If I was going to programmatically reduce it to a single value, I
> would probably take the maximum plausible value at any moment across
> all sensors. Or do this per grouping, if we're getting any useful
> grouping metadata: the hottest probe in the drives is currently: 46C;
> the hottest probe in the cpu is 48C; etc.

Yeah, but sensors doesn't tell us which temp is cpu, which temp is hard
drive, etc. Unless the abstraction you mentioned above does.

> For things like drives or other swappable devices, users might care
> which particular drive is overheating; for cpu or motherboard
> measurement it seems to me not to be very meaningful.
>

- --
Andreas Hasenack
<email address hidden>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzs1KYACgkQeEJZs/PdwpAahACePM3xJk8WDs16pBlsyYCvPL3Z
JXwAoMilWFOrCkMjF6jxGfd+FJJS/Xnb
=86JN
-----END PGP SIGNATURE-----