temperature standard - global config option?

[ please CC replies to me ]

Perusing the kernel sources while investigating watchdog drivers, I notice that in some places, Fahrenheit is used, and in some places, Celsius. It would seem logical to me to have a global config option, so that you *know* that you talk devices either in F or C.

I searched the archives for discussions regarding this, but didn't find anything, apologies if I missed something.

David N. Welton
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
     Personal: http://www.efn.org/~davidw/
         Work: http://www.innominate.com/

Hi!

Please, don't.

Use kelvins *0.1, and use them consistently everywhere. This is what ACPI does, and it is probably right.
Pavel

I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]

Hi,

I'm sorry, by I don't feel like adding 273 to every number I get just to find the temperature of something. What I would do is give configuration options to choose the default (Celsius/centigrade, Kelvin, or [shudder] Fahrenheit) then, when you need to print or output a temperature, send it off to a common converter function so you don't repeat core all over the place.

Just my 0.02 Eurocents (what an ugly word).

Chris Boot
[email protected]

"Modem error handling really su~c%dk,s.^D^D&x@R*cCKo#?C
B,*o#?C!!b    %o#?
NO CARRIER

Kelvin (decikelvin?) is probably a good unit to use in the kernel. If you want something else you convert it in the programs you use to interact with the kernel. This is a usespace issue, I think.

Peter
--
Peter Svensson ! Pgp key available by finger, fingerprint:
<[email protected]> ! 8A E9 20 98 C1 FF 43 E3 07 FD B9 0A 80 72 70 AF
------------------------------------------------------------------------
Remember, Luke, your source will be with you... always...

Peter> Kelvin (decikelvin?) is probably a good unit to use in the Peter> kernel. If you want something else you convert it in the Peter> programs you use to interact with the kernel. This is a Peter> usespace issue, I think.

How about BogoDegrees? Sorry, I will go and shoot myself.

What about keeping times with format similar to "06 June 2001, at 18:06:56 +0200" instead of using miliseconds from 01 Jan 1970 ? ;)

If there is a universally-accepted measure for temperatures, we should use it, and let user space applications make the conversions for us.

Just my 0.02 (eurocents :)

--
José Luis Domingo López
Linux Registered User #189436 Debian GNU/Linux Potato (P166 64 MB RAM)

jdomingo EN internautas PUNTO org => ¿ Spam ? Atente a las consecuencias
jdomingo AT internautas DOT org => Spam at your own risk

FLAME Protection ON....

WARNING -- Do not read if you are humor impaired.

Euro-centric here?

The US is mm/dd/yy or mm/dd/yyyy
Many countries/religions/peoples have different base years, and
calendars...

It happens to have a US format in the current kernel... so what... Convert it in the user processes...

And no... I can't even buy A4 paper.

Let's see.... In one evening ...
Get American attributes out of
Temperature
Time
Date

And replace with European standards.

Next week... change all comments to
Esperanto.

A year from now everything gets converted to Chinese with a 12 year horoscope date cycle.

Then.... The great Hindu hack
Followed by the Orthodox date change ...
Others follow suit....

It reaches its zenith in the great Inca knot display that only obscure researchers can read and is then destroyed in when the Knot Printer tangles up the legs of every computer user on the planet.....

MEANWHILE... M$ developed a bug free product while all the linux hackers were rewriting the comments and I/O....

FLAME Protection OFF!

That's much easier than subtracting 32 and multiplying by 5/9. ;-)

The kernel output should not be configurable. You have tools for printing the information; they can do the calculation for you.

Personally I'd like to see cK (centi-Kelvin).

Matthias Urlichs

Try to reproduce one problem and find another...

I rebuilt from clean source and patch for 2.4.5-ac9 and neglected to add in anything using the joystick. (Which I should have done since this thing has most of the games (I mean "X test utilities") on it.)

This should be pretty straightforward to fix, if it has not been already...

Chokes on link. .config attached.

make[1]: Leaving directory `/usr/src/linux/arch/i386/lib' ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext arch/i386/kernel/head.o arch/i386/kernel/init_task.o init/main.o

init/version.o \
	--start-group \
	arch/i386/kernel/kernel.o arch/i386/mm/mm.o kernel/kernel.o

mm/mm.o fs/fs.o ipc/ipc.o \
drivers/char/char.o drivers/block/block.o drivers/misc/misc.o
drivers/net/net.o drivers/media/media.o drivers/char/agp/agp.o drivers/char/drm/drm.o drivers/ide/idedriver.o drivers/scsi/scsidrv.o drivers/cdrom/driver.o drivers/sound/sounddrivers.o drivers/pci/driver.o

drivers/pcmcia/pcmcia.o drivers/pnp/pnp.o drivers/video/video.o \
	net/network.o \
	/usr/src/linux/arch/i386/lib/lib.a /usr/src/linux/lib/lib.a
/usr/src/linux/arch/i386/lib/lib.a \
	--end-group \
	-o vmlinux

drivers/sound/sounddrivers.o: In function `es1371_probe':
drivers/sound/sounddrivers.o(.text+0x5e5d): undefined reference to `gameport_register_port'
drivers/sound/sounddrivers.o: In function `es1371_remove':
drivers/sound/sounddrivers.o(.text+0x5f71): undefined reference to `gameport_unregister_port'
make: *** [vmlinux] Error 1

[email protected] | Note to AOL users: for a quick shortcut to reply
Alan Olsen | to my mail, just hit the ctrl, alt and del keys.
"In the future, everything will have its 15 minutes of blame."

#
# Automatically generated by make menuconfig: don't edit #

#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y

#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
CONFIG_M586TSC=y
# CONFIG_M686 is not set
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_TSC=y
CONFIG_1GB=y
# CONFIG_2GB is not set
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_SMP is not set

#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y

#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_QUIRKS=y
# CONFIG_PCI_OPTIMIZE is not set
CONFIG_PCI_OLD_PROC=y
# CONFIG_MCA is not set
# CONFIG_VISWS is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
# CONFIG_BINFMT_JAVA is not set
# CONFIG_PARPORT is not set
# CONFIG_APM is not set

#
# Plug and Play support
#
# CONFIG_PNP is not set

#
# Block devices
#
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_IDE=y
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_VIA82C586 is not set
# CONFIG_BLK_DEV_CMD646 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_BLK_DEV_LOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_PARIDE_PARPORT=y
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_DEV_HD is not set

#
# Networking options
#
CONFIG_PACKET=y
CONFIG_NETLINK=y
CONFIG_RTNETLINK=y
# CONFIG_NETLINK_DEV is not set
CONFIG_FIREWALL=y
CONFIG_FILTER=y
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
CONFIG_IP_FIREWALL=y
# CONFIG_IP_FIREWALL_NETLINK is not set
# CONFIG_IP_TRANSPARENT_PROXY is not set
# CONFIG_IP_MASQUERADE is not set
# CONFIG_IP_ROUTER is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
CONFIG_IP_ALIAS=y
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_RARP is not set
CONFIG_SKB_LARGE=y
# CONFIG_IPV6 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_BRIDGE is not set
# CONFIG_LLC is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_FASTROUTE is not set
# CONFIG_NET_HW_FLOWCONTROL is not set
# CONFIG_CPU_IS_SLOW is not set

#
# QoS and/or fair queueing
#
# CONFIG_NET_SCHED is not set

#
# Telephony Support
#
# CONFIG_PHONE is not set
# CONFIG_PHONE_IXJ is not set

#
# SCSI support
#
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set

#
# SCSI low-level drivers
#
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AHA1740 is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_MEGARAID is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_EATA_DMA is not set
# CONFIG_SCSI_EATA_PIO is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_SIM710 is not set
# CONFIG_SCSI_NCR53C7xx is not set
# CONFIG_SCSI_NCR53C8XX is not set
CONFIG_SCSI_SYM53C8XX=y
CONFIG_SCSI_NCR53C8XX_DEFAULT_TAGS=4
CONFIG_SCSI_NCR53C8XX_MAX_TAGS=32
CONFIG_SCSI_NCR53C8XX_SYNC=20
# CONFIG_SCSI_NCR53C8XX_PROFILE is not set
# CONFIG_SCSI_NCR53C8XX_IOMAPPED is not set
# CONFIG_SCSI_NCR53C8XX_PQS_PDS is not set
# CONFIG_SCSI_NCR53C8XX_SYMBIOS_COMPAT is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PCI2000 is not set
# CONFIG_SCSI_PCI2220I is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_ISP is not set
# CONFIG_SCSI_QLOGIC_FC is not set
# CONFIG_SCSI_SEAGATE is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_DEBUG is not set

#
# I2O device support
#
# CONFIG_I2O is not set
# CONFIG_I2O_PCI is not set
# CONFIG_I2O_BLOCK is not set
# CONFIG_I2O_SCSI is not set

#
# Network device support
#
CONFIG_NETDEVICES=y

#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=m
# CONFIG_BONDING is not set
# CONFIG_EQUALIZER is not set
# CONFIG_ETHERTAP is not set
# CONFIG_NET_SB1000 is not set

#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
# CONFIG_EL1 is not set
# CONFIG_EL2 is not set
# CONFIG_ELPLUS is not set
# CONFIG_EL16 is not set
CONFIG_EL3=y
# CONFIG_3C515 is not set
CONFIG_VORTEX=y
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_RTL8139 is not set
# CONFIG_NET_ISA is not set
# CONFIG_NET_EISA is not set
# CONFIG_NET_POCKET is not set

#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_SK98LIN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_RADIO is not set

#
# Token ring devices
#
# CONFIG_TR is not set
# CONFIG_NET_FC is not set
# CONFIG_RCPCI is not set
CONFIG_SHAPER=m

#
# Wan interfaces
#
# CONFIG_HOSTESS_SV11 is not set
# CONFIG_COSA is not set
# CONFIG_SEALEVEL_4021 is not set
# CONFIG_SYNCLINK_SYNCPPP is not set
# CONFIG_LANMEDIA is not set
# CONFIG_COMX is not set
# CONFIG_HDLC is not set
# CONFIG_DLCI is not set
# CONFIG_SBNI is not set

#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set

#
# IrDA (infrared) support
#
# CONFIG_IRDA is not set

#
# ISDN subsystem
#
# CONFIG_ISDN is not set

#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set

#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=y
# CONFIG_SERIAL_CONSOLE is not set
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
CONFIG_UNIX98_PTYS=y
CONFIG_UNIX98_PTY_COUNT=256
# CONFIG_MOUSE is not set

#
# Joysticks
#
# CONFIG_JOYSTICK is not set
# CONFIG_QIC02_TAPE is not set
# CONFIG_WATCHDOG is not set
# CONFIG_NVRAM is not set
CONFIG_RTC=y

#
# Video For Linux
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DTLK is not set

#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set

#
# Filesystems
#
# CONFIG_QUOTA is not set
CONFIG_AUTOFS_FS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_FAT_FS is not set
# CONFIG_MSDOS_FS is not set
# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_MINIX_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
CONFIG_DEVPTS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_EFS_FS is not set

#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_SUNRPC is not set
# CONFIG_LOCKD is not set
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set

#
# Partition Types
#
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MAC_PARTITION is not set
# CONFIG_SMD_DISKLABEL is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
CONFIG_NLS=y

#
# Native Language Support
#
CONFIG_NLS_DEFAULT="cp437"
CONFIG_NLS_CODEPAGE_437=m
CONFIG_NLS_CODEPAGE_737=m
CONFIG_NLS_CODEPAGE_775=m
CONFIG_NLS_CODEPAGE_850=m
CONFIG_NLS_CODEPAGE_852=m
CONFIG_NLS_CODEPAGE_855=m
CONFIG_NLS_CODEPAGE_857=m
CONFIG_NLS_CODEPAGE_860=m
CONFIG_NLS_CODEPAGE_861=m
CONFIG_NLS_CODEPAGE_862=m
CONFIG_NLS_CODEPAGE_863=m
CONFIG_NLS_CODEPAGE_864=m
CONFIG_NLS_CODEPAGE_865=m
CONFIG_NLS_CODEPAGE_866=m
CONFIG_NLS_CODEPAGE_869=m
CONFIG_NLS_CODEPAGE_874=m
CONFIG_NLS_CODEPAGE_932=m
CONFIG_NLS_CODEPAGE_936=m
CONFIG_NLS_CODEPAGE_949=m
CONFIG_NLS_CODEPAGE_950=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_8=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m

#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VIDEO_SELECT is not set
# CONFIG_MDA_CONSOLE is not set
# CONFIG_FB is not set

#
# Sound
#
# CONFIG_SOUND is not set

#
# Kernel hacking
#
# CONFIG_MAGIC_SYSRQ is not set

Your attached .config (why was it in base64?) has
# CONFIG_SOUND is not set
which is completely incompatible with the above error. Either you manually overrode the compile or you enclosed the wrong .config.

It was in base64 because I sent it as an attachment with Pine.

Weird. I took it from the kernel I had just built. (And gotten that error.)

I will try and reproduce it again.

[email protected] | Note to AOL users: for a quick shortcut to reply
Alan Olsen | to my mail, just hit the ctrl, alt and del keys.
"All power is derived from the barrel of a gnu." - Mao Tse Stallman

Followup to:  <[email protected]>
By author:    Peter Svensson <[email protected]>
In newsgroup: linux.dev.kernel

Decikelvins is a good bet if we feel that fitting into 16 bits is a necessary, or the width of things is limited. Otherwise I would go for millikelvins on the general principle that creating interfaces too narrow is really painful.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Hi,

It seems that a lot of people are agreeing that the unit should be a multiple of 1 kelvin but to my eyes there are two camps and I just want to make sure that everyone's being clear with their notation.

If the kernel tells me the temperature is 1 (one) what should that mean? If it's spitting out 0.1*<temperature in K> as people are claiming the ACPI stuff does then 1 means 10 kelvin or 1 dekakelvin, not a

                                            ^^^^

decikelvin as other people are saying they would prefer to see used. Or are people being braindamaged and by "0.1*K" they mean that ACPI spits out 10*<temperature in K>? Which would then mean that everyone does agree afterall that the unit should be a decikelvin although they don't necessarily know what multiplication means :-).

-Kipp

I do believe that by 0.1*K everyone means a basic unit of 0.1 K, i.e. with an int of 1 meaning 0.1 Kelvin, analogically 0.01*K meaning an int of 1 means 0.01 Kelvin - hence the proper names of deci and centi-Kelvins.

Perosnally I believe we should take normal (32 bit) ints (perhaps more on 64bit architectures?) and encode using 0.001*K (i.e. miliKelvins), I do believe space is not an issue here and this leaves us the most precision and logical system - Farenhait is screwed, and Celsius/Centigrade are not to good since don't begin at absolute zero.

Anyway just my two cents.

Maciej.

out

One question here which has been bugging me all through this thread, is there any hardware that actually measures to that precision and accuracy ?? certanally 0.1K intervals, but 0.01 ?, and at 0.001K intervals ? is this going ott ? and what use would people have with measureing system temp to 0.01K precision ? --i would assume that the accuracy of the temp sensors is less than that...

well, there are my two cents ...

Farenhait is irritating, yes, and the brits that suggested it are becoming a dying bread, although still large in number, things more so use Celsius nowerdays.

btw, the kelvin scale is a centigrade scale, like wise, so is the celsius scale ...

Thanks,,
Dave

Hi!

Actually there's one good reasons to use milikelvins:

0 Celsius != 2732 deciKelvin, but
0 Celsius == 273150 miliKelvin ;-)
Pavel

Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Hi!

No. Sorry. Create nice tool to display info for you. We are talking about output from kernel. It *must not* be configurable. Or do you want your programs to read 58 from /proc/acpi/thermal/1/status and then reading /proc/units to see if it is celsius or farenhait.

ACPI is already using 0.1*K, so everything should use that to be consistent.
Pavel

The best software in life is free (not shareware)!		Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+

Which is the data type for temperature ? Would not it be better to use 0.01*K ? So you get the full accuracy of a short.

J.A. Magallon                           #  Let the source be with you...        
mailto:[email protected]
Linux Mandrake release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686

Hello All!

Kelvins good idea in general - it is always positive ;-)

0.01*K fits in 16 bits and gives reasonable range.

but may be something like K<<6 could be a option? (to allow use of shifts
instead of muls/divs). It would be much more easier to extract int part.

just my 2 eurocents.

begin:vcard
n:Filiapau;Ihar
tel;pager:+375 (0) 17 2850000#6683 tel;fax:+375 (0) 17 2841537
tel;home:+375 (0) 17 2118441
tel;work:+375 (0) 17 2841371 x-mozilla-html:TRUE
url:www.iph.to
org:Enformatica Ltd.;Linux Developement Department adr:;;Kalinine str. 19-18;Minsk;BY;220012;Belarus version:2.1
email;internet:[email protected] title:Software Developer
note:(none)
x-mozilla-cpt:;18368
fn:Philips
end:vcard

Why not make it in Celsius ? Is more easy to read it this way.

No, because then the software must handle negative numbers for cooled computers. CentiKelvin is fine. Do C=cK/100-273.15 if you really must... but you still have a number that is useless to a human. Humans need a seconds-to-destruction value or an alarm.

Negative temperatures do not really exist.

Are you really sure about this ?

It was posted by L. K. where I now add my 0.02 EUR...

I am. I made Abitur (german degree after 13yrs of school) with physics being an important course, and there can not be any temperature less than 0 K (or -273.15°C if you want). This is because temperature is nothing but the movement of pieces of materie (and even photons, ergo energy).

-mirabilos

C:\>debug
-e100 EA F0 FF 00 F0
-g
--->Enjoy!

Thanks for enlightening me. Physics is not one of my strong points. I'm used to the Celsius scale, maybe that's why I didn't belive the first time.

Regads,

Then you must have blown your quantum finals. Royally. ESPECIALLY
after that statement about "temperature is nothing but the movement of pieces of materie". Not even close, once you get into the quant.

Mathematically and quantum mechanically, negative absolute
temperatures do exist. In quantum mechanics, temperature is expressed as probability populations in various quantum states.

Absolute zero is the quantum state were all particles are in
the ground state. An infinite temperature is, quantum mechanically, the condition where all states, ground and energetic, have an equal probability of population.

A "population inversion" (a condition where the energized states
are more likely to be populated than the ground states) is at the heart of many things we take for granted today such as lasers, masers, leds, NMR (Nuclear Magnetic Resonance) and MRI (the medical use of NMR).

Those "population inversions" represents an "energized state"
that is more energetic than the state that would be present in a steady state infinite temperature.

Mathematically, those states can actually be treated as negative
absolute temperatures. IOW, negative absolute temperatures are actually hotter than infinite.

It's true that these are not STEADY STATE conditions or in
equilibrium (which is how we take advantage of populations inversions - by their actions in returning to equilibrium), but the math still works. Just check out a few issues of Scientific American from the mid 1970's on "Negative Absolute Temperatures in Nuclear Magnetic Resonance" and to the scientific journals they reference. I won an argument with a physics prof (PhD in high energy physics) over that very issue when I did the same thing in a 400 level senior level physics lab on NMR back then. It's actually pretty damn simple, once you work the math, and it agravated him that he didn't believe it but couldn't argue with the math till he saw the work and publication from someone else. Then he conceeded that I had him and I had been right.

IAC... Negative absolute temperatures are about as meaningless
to this particular discussion as is expressing the temperature in 1/100s of a Kelvin which would have a precision than exceeds the accuracy of the measuring chips by two orders of magnitude. IOW... Both are silly and meaningless to this case. One is out of range in magnitude and one is out of the range of accuracy.

 Michael H. Warfield    |  (770) 985-6132   |  [email protected]
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Nobody is doubting that population inversions do exist. And you also can do all kind of mathematics with it if you like and even calculate a temperature. But I think you shouldn't interprete this kind of temperature as something that is macroscopically existant or even measurable. You also wouldn't say quantum wave functions do exist, would you ?

I agree and I think we shouldn't get too out of topic ...

--
Thomas

Hi,

Excuse me, but I don't think that we can get computer temperature sensors as we know them to measure temperatures of matter in quantum states. Even if, one day, we built a usable quantum computer which might need temperature measurements, I doubt that the Linux kernel would run on it without being totally rewritten.

Anyhow, I like the discussion. I love anything to do with quantum physics!

Chris Boot
[email protected]

#define QUESTION ((2b) || (!2b))

Actually, the REAL point I was TRYING to make (and doing a really
shabby job of it) is that some of this needs a little dose of reality. We don't have sensors that are accurate to 1/10 of a K and certainly not to 1/100 of a K. Knowing the CPU temperature "precise" to .01 K when the accuracy of the best sensor we are likely to see is no better than

+- 1 K is just about as relevant as negative absolute temperatures.
(Ok...  Ok...  Actually it did annoy me, as someone who majored in

physics, to see someone else write that because physics was "a major course" for them that they could say definitively that there was no such thing and that temperature was only the movement of materials. But it was a perfect opening to try an exercise in absurdity. It just seems to have flopped. My fault.)

Trying to keep this relevant to the topic of the Linux kernel,
I was trying to impress people with the absurdity. That's why I closed that message about the precision being just as silly. Unfortunately, I need to be a little more explicit about things like that since it seems that my forey into absurdity went right over several peoples heads. Again... My fault.

Even if we had or could, anticiplate, sensors with a +- .01 K,
the relevance of knowing the CPU temperature to that precision is lost on me. I see no sense in stuffing a field with meaningless bits just because the field will hold them. In fact, this "false precision" quickly leads to the false impression of accuracy. Based on several messages I have seen on this thread and in private E-Mail, there are a number of people who don't seem to grasp the fundamental difference between precision and accuracy and truely don't understand that adding meaningless precision like this adds nothing to the accuracy.

I can see maybe making it precise to .1 K. But stuffing the bits
in there to be precise to .01 K just because we have the bits and not because we have any realistic information to fill the bits in with, is just silly to me. Just as silly as allowing for negative numbers in an absolute temperature field. We have the bits to support it, but why?

I do agree that it should be in K, though.

Mike

 Michael H. Warfield    |  (770) 985-6132   |  [email protected]
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

...

The bits are free; the API is hard to change.
Sensors might get better, at least on high-end systems. Rounding gives a constant 0.15 degree error.
Only the truly stupid would assume accuracy from decimal places. Again, the bits are free; the API is hard to change.

One might provide other numbers to specify accuracy and precision.

I really do not belive that for a CPU or a motherboard +- 1 degree would make any difference.

If a CPU runs fine at, say, 37 degrees C, I do not belive it will have any problems running at 38 or 36 degrees. I support the ideea of having very good sensors for temperature monitoring, but CPU and motherboard temperature do not depend on the rise of the temperature of 1 degree, but when the temperature rises 10 or more degrees. I hope you understand what I want to say.

Regards,

Of course I understand. Motorola offers 4-degree resolution, with a random offset of up to 12 degrees. (calibration is possible) You seem to need another reminder that THE BITS ARE FREE.

Why would you even consider trying to squeeze out a few bits? You can't be absolutely sure that they will never be useful.

Hi,

Well then, tell all the teachers in this world that they're stupid, and tell everyone who learnt from them as well. I'm in high school (gd. 11, junior) and my physics teacher is always screaming at us for putting too many decimal places or having them inconsistent. There are certain situations where adding a ±1 is too cumbersome and / or clumsy, so you can specify the accuracy using just decimal places.

For example, 5.00 would mean pretty much spot on 5 (anywhere from 4.995 to 5.00499), wheras 5 could mean anywhere from 4.5 to 5.499.

Please, let's quit this dumb argument. We all know that thermistors and other types of cheap temperature gauges are very inaccurate, and I don't think expensive thermocouples will make it into computer sensors very soon. Plus, who the hell could care whether their chip is at 45.4 or 45.5 degrees? Does it really matter? A difference of 0.1 will not decide whether your chip will fry.

Just my 2 eurocents.

Chris Boot
[email protected]

DOS Computers manufactured by companies such as IBM, Compaq, Tandy, and
millions of others are by far the most popular, with about 70 million
machines in use worldwide. Macintosh fans, on the other hand, may note
that cockroaches are far more numerous than humans, and that numbers
alone do not denote a higher life form.
New York Times, November 26, 1991

[email protected] (Chris Boot) wrote on 08.06.01 in <B7471019.F9CF%[email protected]>:

*All*?

Ok, *yours*.

But yours is not all. I certainly don't remember ever seeing that attitude in school.

And yes, this behaviour *is* stupid. Someone who thinks like that should never be allowed to become a science teacher.

MfG Kai

*cough*

I've been taught by every Maths, Engineering and Physics teacher/lecturer I've encountered to write down significant figures consistent with the precision of the value. So blindly writing down a value of 59.42886726469 ±2°C is obviously ludicrous, even if that's what my calculator gives me. I should instead write 59 ±2°C, since that is the most precision I can possibly know it to. With some advanced measuring techniques it *may* be acceptable to write 59.43 ±2°C *at most*, and then only if you really know why you need the extra information.

The UK education system is one of the better ones available, and the above philosophy is consistently held throughout it. I'd be well advised not to argue, especially since it's common sense.

--------------------------------------------------------------
from:     Jonathan "Chromatix" Morton
mail:     [email protected]  (not for attachments)
website:  http://www.chromatix.uklinux.net/vnc/
geekcode: GCS$/E dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$
          V? PS PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
tagline:  The key to knowledge is not to rely on people to teach you it.

Followup to:  <B7471019.F9CF%[email protected]>
By author:    Chris Boot <[email protected]>
In newsgroup: linux.dev.kernel

This, again, is a presentation issue, and is irrelevant to the intricacies of fixed-point arithmetric.

Does it really matter NOW? No. However, 1 cK is a convenient unit and a good use of bits. Can we guarantee it won't matter in the future, especially not on a CPU which may very well require complex algorithms to eke out optimal performance in a thermally-challenged environment (more than just simple trip points.) Now it gets interesting! I have actually seen, in the lab, an algorithm which required complex guesswork, because it required information below the noise level of the sensor (and yes, it *is* possible to obtain that information.)

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

What they teached me in school is about the same. But the rule for the precision was to use two signicifant(?) decimals. So you end up with 59.4 ± 2.0 °C or something.

Also note that you have to round up the precision, so it couldn't have been 2.01, but could have been 1.01 the way you wrote it.

Kurt

Twice a year I'm a judge at science fairs. Once at the local
level and once at the state level. I generally judge on the senior level in the physics category. All too often I have a hard time even convincing some of my fellow judges.

Each year there is at least one project where some student has
used "fancy scientific equipment" to make measurements of impressive precision and beautiful results. Till you look closer and you find that their standard deviation is as large as their averages and their raw test results are all over the map. With 5 or more decimal places of precision, you find that their sample sizes and proceedures don't even support one or two decimal places, if they are lucky.

If it were not for the fact that I don't think they are really
that good at it, I would give them an award for "if you can't dazzle them with brilliance, baffle them with bullshit". Unfortunately, they honestly don't KNOW the difference between precision and accuracy. We often judge between a half a dozen and a dozen exhibits. This comes up every year and gets written up in comments every year. Of course, you can't be harse in judging these things and most of them really do make a legitimate effort, but it is difficult to tactfully explain to someone why their elaborate and extremely detailed results amount to utter jibberish. (To the smartasses who are about to fire off the obligatory smart remarks: Trust me, I am much more tactful with those students than I am on this list... Maybe I shouldn't be. Read that either way.)

What's more apalling is that their teachers did not catch this
and I have to point out the fatal flaws to a lot of my co-judges who were impressed with the scientific prowess of these individuals.

No... The average person, NO, the vast majority of people,
DO assume accuracy from decimal places and honestly do not know the difference between precision and accuracy. I've had comments on this thread in private E-Mail the reinforce this impression.

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.

Even the rounding error vis-a-vis the .15 is silly and irrelevant!
If the sensor is +- 1 degree, you can't even measure the rounding error, even if you HAVE two decimal places. With that degree of accuracy, you are no better off than 273 with no decimal places. Worrying about rounding error on .15 when the accuracy is in the units is exactly the kind of misinformed false precision that I worry about. You actually though that the .15 was significant enough to worry about round error when, in fact, it will be impossible to measure with the equipment available in the environment of discourse.

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

 Michael H. Warfield    |  (770) 985-6132   |  [email protected]
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

[Snip] (Mike writes a bunch a good stuff)

[snip]

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

There are processors with temperature measurement built right into the silicon.

This makes sense. Heat increases resistance, which generates heat. At some point, a tiny increase will cause thermal run-away.

Followup to:  <[email protected]>
By author:    "Albert D. Cahalan" <[email protected]>
In newsgroup: linux.dev.kernel

As far as I know, ALL current microprocessors do.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

The current x86 setup uses a small sensor sitting under the CPU socket. Intel's more recent output does have a heat sensor of its own, for thermal protection purposes - presumably this is exported to the chipset - but older ones don't appear to...

James.

Current Intel chips have a sensor built right into the die of the processor itself -- voila, close enough to the critical junction temperature for any purpose. Many workstation CPUs have a similar feature, and the other x86 manufacturers either do or have plans to include such a beast.

Charles

-----------------------------------------------------------------------
Charles Cazabon                            <[email protected]>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------

...

Fine. Most user apps can round to the nearest degree, or even display the values "cool", "warm", "hot", and "BURNING!". The kernel API should not be so limiting.

The 0.15 may mean the difference between:

a. less than 0.005 chance of exceeding 370 degrees b. less than 0.01 chance of exceeding 370 degrees

for a measurement that might be 365 degrees.

No, at any level of precision. I'd sure want to know if the device is specified as "resolution 8 degrees, standard deviation 23".

This information is fairly important. The user is responsible for defining acceptable risk, and the app should be able to provide a warning or shutdown based on this.

For typical PC hardware, one might assume that the device is a cheap piece of junk 2 mm below the CPU. (with quite a bit of lag!) The lag ought to be specified too of course.

...

I hope you don't think people would assume that a "float" always has useful data in all 23 fraction bits. It is a similar case.

So here you go, a kernel-safe conversion from C to K. It works from 0 to 238 degrees C. Print as hex, so user code can toss it into a union or maybe abuse scanf. Adjust as needed for F to K or for hardware with greater resolution.

/* unsigned int degrees C --> float degrees K */
unsigned ic_to_fk(unsigned c){
unsigned exponent;
unsigned tmp;

tmp = (c<<23) + 0x88933333; /* Kelvin shifted 23 left */ exponent = 127; /* IEEE floating-point bias */

  while(tmp&0xff000000){
    tmp >>= 1;
    exponent++;

}
tmp &= 0x007fffff; /* keep only the fraction */
tmp |= exponent<<23;
return tmp;
}

Followup to:  <[email protected]>
By author:    "Albert D. Cahalan" <[email protected]>
In newsgroup: linux.dev.kernel

I hope you're not seriously suggesting we're using floats for this...

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

[snip]
MHW> Yes, bits are free, sort of... That's why an extra decimal
MHW> place is "ok". Keeping precision within an order of magnitude MHW> of accuracy is within the realm of reasonable. Running out to MHW> two decimal places for this particular application is just MHW> silly. If it were for calibrated lab equipment, fine. But not MHW> for CPU temperatures.

You do introduce some rounding errors if the measurement isn't in Celsius or Kelvin. Ie, you must do a conversion because the hardware isn't in the desired units. In this case, the extra precision will be beneficial.

If you are going your route, you should send error bars with all the measurements ;-) Fine, too many decimals leads to a false sense of security. However, no one knows the accuracy of any future temperature sensors so why not accommodate the possibility. Certainly some band gap semis can give a pretty good measurement if you have good coupling. If the temperature sensor was built into the CPU, you might actually have accuracy!

regards,
Bill Pringlemeir.

This thread keeps going and going and going...

Take for examples the motherboards with temperature sensors on them. At some point it will display the temperature of the motherboard. This rises
questions: The motherboard will not have the same temeprature in two distinct points. The temperature will be highere where there are presne some thermistors or transistors that need cooloing and have a heatsink on top of them. So, where are the sensors on the motherboard put ? I don't think that there are a lot of them and then to display the average temperature. This would be a stupid thing to do. You want to know the temperature of the motherboard for different resons. If you have a case that it is sealed by the manufacturer and cannot keep it open to allow the components to cooldown when things get hot inside or outside (in the summer), you will have to rely on the motherboard sensors. And if it happens to have in your computer some graphics card that generates a lot of heat (like a Voodoo 2, or GeForce without a cooler), a TV tunner, some of the heat generated will be passed on to the motherboard. And some motherboard manufacturers insert beetween PCI/ISA slots different componenents that can be affected by the heat generated by the cards in the slots. And your confidence in the sensors in the motherboard disapperas. The only thing you can trust nowadays is the one that messures the temperature of the CPU (not very accurate). We can talk about accuracy of temperature measurment when the sensors inside our computer get as good as those used in a laboratory. Untill then ...

I haven't encountered any CPU with builtin temperature sensors.

and going, and going ..... and still going .....

and still going .........

Regards,

/me

Eh, all Pentium class cpus have a build in sensor for core temperature (I believe Athlons too). It's just the logic which is outside in form of a A/D converter connected to a I2C bus.

Regards,

  Steffen Persvold               Systems Engineer
  Email : mailto:[email protected]     Scali AS (http://www.scali.com)
  Tlf   : (+47) 22 62 89 50      Olaf Helsets vei 6
  Fax   : (+47) 22 62 89 51      N-0621 Oslo, Norway

Hi,

Well, I've got an Apple iMac (tee hee hee) with a PowerPC G3 (or 750 for you number guys). I know for sure that all of the G3 / G4 chips have temperature sensors built onto the CPU core.

Mine's showing 23 degrees Celsius at the moment.

and going, and going, and going...

    .-.         Chris Boot
    /v\      [email protected]
   // \\
  /(   )\    L   I   N   U   X
   ^^-^^    >Phear the Penguin<

Followup to:  <[email protected]>
By author:    "Michael H. Warfield" <[email protected]>
In newsgroup: linux.dev.kernel

Do you want to bet that that is going to remain the case, or are you just assuming the current state of the art will continue to be used forever? That is extremely poor interface design. Designing interfaces is NOT the same thing as judging science fairs and presenting data.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Lets see, somebody can develop lab equipment (dont think on PTRs or thermistors in common world) that givee 10e-3 precission, and you are just making linux not suitable to control that hardware. Think open. What is the real difference between managing temperatures with a short or a long ?. Is it really needed to fit it in a short ??!!!
I would use an unsigned long with fixed point and all done.

J.A. Magallon                           #  Let the source be with you...        
mailto:[email protected]
Linux Mandrake release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686

No, we are not talking lab instrumentation here. We are talking
about CPU monitoring. Lab instrumentation is a whole different issue with things like the IEEE bus and such. Lab instrumentation would require it's own drivers and interface.

Mike

 Michael H. Warfield    |  (770) 985-6132   |  [email protected]
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

Sorry, I thought you were talking about general temperature handling in kernel, both for LM78, ACPI or any driver that managed that kind of data.

J.A. Magallon                           #  Let the source be with you...        
mailto:[email protected]
Linux Mandrake release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686

It's easier for you as a user to read, but slightly harder to deal with inside the code. It's really a user-space issue, inside the kernel should be as standardized as possible, and Kelvins make the most sense there.

-Dave

Hi,

OK, I think by now we've all agreed the following:
- The issue is NOT displaying temperatures to the user, but a userspace program reading them from the kernel. The userspace program itself can do temperature conversions for the user if he/she wants.
- The most preferable units would be decikelvins, as the value can give a relatively precise as well as wide range of numbers ranging from absolute zero to about 6340 degrees Celsius ((65535 / 10) - 273) which is well within anything that a computer can operate. It also gives us a good base for all sorts of other temperature sensing devices.

Do we all agree on those now?

Chris Boot
[email protected]

#define QUESTION ((2b) || (!2b))

...

I nearly do.

There isn't any need to cram the data into 16 bits. The offset to Celsius is 273.15 degrees.
So hundredths of a degree, in Kelvin, is a better choice.

[Let's see if I can argue boths sides of this fence plus a
third here.]

Who cares if you cram it into 16 bits. It still works.

I think we can agree that negative degrees Kelvin are not relevant
(outside of VERY esoteric physics circles where negative absolute temperatures are real and represent quantum mechanical states in "population inversions". i.e. Quantum mechanical temperatures hotter than infinite - reference SciAm back in the mid 1970s. I won an arguement with a PhD high energy physics prof over that point back then).

Therefore, we have a 16 bit unsigned quantity which gives us a
range of 0 - 65535. Translated as hundreths of a Kelvin, that works out to 0 -> 655.35 K. Ok... That's -273.15 C -> 382.20 C. And... That's roughly -524 F -> 720 F. Ok... That covers everything from superfluid Helium through MELTS GLASS with room for bobble.

In 16 bits.

What's the problem?

Other than what's the need for two digits of precision in something
that does not have even 1/100 of that accuracy?

A plague of many measuring systems is "false precision". Why
provide precision (the units to which a measurement can be divided or quantized) when the accuracy can not support it. I would be amazed if ANY CPU temperature monitors were any more accurate than to a degree C/K or ~2 degrees F). Hundreths of a degree K is basically silly nonsense. The precision even for tenths of a degree K or C are just not supported by the accuracy of the measuring device and are meaningless. Even if it COULD provide even something remotely similar to that level of precision in it's accuracy, is it really relevant to know the CPU temperature to 1/100 of a degree C?

Looking at most temperature measuring chips today, unless you are
looking at lab-quality high-precision high-accuracy sensors, you are really talking about a 12 bit sensor (+- a couple of bits) with an accuracy of not much better than +-1 C.

Add the tenths if you want to be silly but returning hundreths
is just meaningless jibberish.

Mike

 Michael H. Warfield    |  (770) 985-6132   |  [email protected]
  (The Mad Wizard)      |  (678) 463-0932   |  http://www.wittsend.com/mhw/
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

celsius is probably a sensible default - lots of the world uses it now.

j.

"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson

If something is done, Celsius should be default (as the US is brain-dead like that; nearly everywhere else uses Celsius as the standard) and fahrenheit as an option.

I wrote a patch for the 'sensors' utility in lm_sensors that did just that; supplied fahrenheit conversion for the sensors via a commandline option. Perhaps there could be a config option in the kernel (or a proc entry/ioctl?) that controls this.

Kelsey Hudson [email protected]
Software Engineer
Compendium Technologies, Inc (619) 725-0771
---------------------------------------------------------------------------

The spec is farenheit

Problem is decimals and floating point... I suppose kernel people would prefer whatever, but suited to get full intXX_t range, say ºC/10. And if you do not want signs, centi-kelvin is the better choice:xxx.xx, five digits, a short goes to 655-273=382 ºC-

J.A. Magallon                           #  Let the source be with you...        
mailto:[email protected]
Linux Mandrake release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686

Kernel is worldwide, should not use anlo-saxon shifted units. Use the International System of Units (SI)
http://physics.nist.gov/cuu/Units/units.html

Temperature measures in kelvins.

--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Linux Mandrake release 8.1 (Cooker) for i586
Linux werewolf 2.4.5-ac9 #1 SMP Wed Jun 6 09:57:46 CEST 2001 i686

Hmmm... I don't see bogomips on this list! :-)

Paul Fulghum [email protected]
Microgate Corporation www.microgate.com

Hi!

What specs?

ACPI specs use K *0.1, I'd prefer that. Pavel

The best software in life is free (not shareware)!		Pavel
GCM d? s-: !g p?:+ au- a--@ w+ v- C++@ UL+++ L++ N++ E++ W--- M- Y- R+

The spec for watchdog/temperature monitor devices (/dev/temperature)

For new stuff - for ACPI etc definitely

Absolutely. We chide Microsoft for not following standards, so we should definitely follow the SI standards, which are much firmer than any internet standards.

Hilsen Harald.

/dev/temperature is in farenheit. It was specified by someone in the UK several years ago and we are stuck with it that way really.

Newer API's should probably use celcius/kelvin

So it is not possible to have an 'opt-in' kernel config (or sysctl, I suppose) option (default is off) that allows you to say "ok, on this box, everything is going to be in Fahrenheit/Celsius/Kelvin"? It would be something that the admin decides to turn on, hopefully conscious of the fact that this may entail other changes.

My thought was that it would be nice to be able to configure this, so that one could work with the units one is most comfortable with. 104 Fahrenheit tells *me* a lot more than 313 Kelvin. Maybe Elbonians are more comfortable working with Kelvin.

Well, anyway, it was just an idea that popped into my head when looking around, I'll step aside and let you guys figure out what is best:-) (Please do keep me CC'ed though).

Thankyou for your time,

David N. Welton
Free Software: http://people.debian.org/~davidw/
   Apache Tcl: http://tcl.apache.org/
     Personal: http://www.efn.org/~davidw/
         Work: http://www.innominate.com/