On Sat, 08 Sep 2012 21:15:21 +0200, Andreas Hartmann wrote: > Clemens Ladisch wrote: > > Guenter Roeck wrote: > >> On Sat, Sep 08, 2012 at 06:34:16PM +0200, Andreas Hartmann wrote: > >>> I'm getting this temperature after more than one hour of activity > >>> (mostly idle, load of the machine is: 0,11, 0,17, 0,21): > >>> > >>> temp1: +14.5°C (high = +70.0°C) > >>> > >>> 14.5°C is completely impossible as the surrounding temperature is > >>>> 20°C. > > > > Documentation/hwmon/k10temp says: > > | There is one temperature measurement value, available as temp1_input in > > | sysfs. It is measured in degrees Celsius with a resolution of 1/8th degree. > > | Please note that it is defined as a relative value; to quote the AMD manual: > > | > > | Tctl is the processor temperature control value, used by the platform to > > | control cooling systems. Tctl is a non-physical temperature on an > > | arbitrary scale measured in degrees. It does _not_ represent an actual > > | physical temperature like die or case temperature. Instead, it specifies > > | the processor temperature relative to the point at which the system must > > | supply the maximum cooling for the processor's specified maximum case > > | temperature and maximum thermal power dissipation. > > I already read this, too. > > My point of view is: If sensors says: "temp1: +14.5°C (high: +70°C)" > then it is a temperature of +14.5°C and nothing else. If this value > isn't a physical temperature (like the room temperature e.g.), why is it > called temperature if it isn't one? Because the maintainers of that code (and I mean the driver, the whole subsystem, the user-space library and many user-space applications) have a limited time to devote to ill-designed hardware. You think you can do better? Join the development team, design the interface, write the code. > However, if it is an instrument to manage a fan (or maybe a complete > cooling system), I most probably would use a percentaged value, which > reveals something about the actual required cooling capacity for the > individual system. > At least it would avoid misunderstanding IMHO. The text Clemens quoted and you claim you have read, is supposed to avoid misunderstanding. Sure, the current situation is not perfect, but the alternative currently is between that and nothing. Most users have told us they prefer that to nothing. If you don't agree, just don't user the driver. If anyone wants to add support for relative, arbitrary unit temperature sensors to the whole monitoring stack, they are welcome to contribute the code. Good night, -- Jean Delvare _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
