temperature standard - global config option?

temperature standard - global config option?

[David N. Welton]

[ 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/

Re: temperature standard - global config option?

[Pavel Machek]

Hi!

> [ 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.

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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org

Re: temperature standard - global config option?

[Chris Boot]

Hi,

> Please, don't.
> 
> Use kelvins *0.1, and use them consistently everywhere. This is what
> ACPI does, and it is probably right.

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
bootc@worldnet.fr

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

Re: temperature standard - global config option?

[Peter Svensson]

On Wed, 6 Jun 2001, Chris Boot wrote:

> 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.

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:
<petersv@psv.nu>    ! 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...

Re: temperature standard - global config option?

[Bill Pringlemeir]

>>>>> "Peter" == Peter Svensson <petersv@psv.nu> writes:

 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.

Re: temperature standard - global config option?

[H. Peter Anvin]

Followup to:  <Pine.LNX.4.33.0106061814470.1655-100000@cheetah.psv.nu>
By author:    Peter Svensson <petersv@psv.nu>
In newsgroup: linux.dev.kernel
> 
> 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.
> 

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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: temperature standard - global config option?

[Kipp Cannon]

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

Re: temperature standard - global config option?

[Maciej Zenczykowski]

On Wed, 6 Jun 2001, Kipp Cannon wrote:

> 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 :-).

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.

Re: temperature standard - global config option?

[David Flynn]

> On Wed, 6 Jun 2001, Kipp Cannon wrote:
>
> > 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 :-).
>
> 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),

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 ...


> 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.
>

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

> Anyway just my two cents.
>
> Maciej.
>

Re: temperature standard - global config option?

[Pavel Machek]

Hi!

> 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 :-).

I admit that I do not know what multiplication means ;-).

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

Re: temperature standard - global config option?

[Pavel Machek]

Hi!

> > 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.
> > 
> 
> 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.

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.

Re: temperature standard - global config option?

[Matthias Urlichs]

At 18:06 +0200 2001-06-06, Chris Boot wrote:
>I'm sorry, by I don't feel like adding 273 to every number I get just to
>find the temperature of something.

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

>  What I would do is give configuration
>options to choose the default (Celsius/centigrade, Kelvin, or [shudder]
>Fahrenheit)

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

es1371 compile issue in 2.4.5-ac9

[Alan Olsen]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1705 bytes --]

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


alan@ctrl-alt-del.com | 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."

[-- Attachment #2: Type: TEXT/PLAIN, Size: 9959 bytes --]

#
# 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

Re: es1371 compile issue in 2.4.5-ac9

[Keith Owens]

On Wed, 6 Jun 2001 14:45:10 -0700 (PDT), 
Alan Olsen <alan@clueserver.org> wrote:
>I rebuilt from clean source and patch for 2.4.5-ac9 and neglected to add
>in anything using the joystick.
>
>ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext ...
>	-o vmlinux
>drivers/sound/sounddrivers.o: In function `es1371_probe':
>drivers/sound/sounddrivers.o(.text+0x5e5d): undefined reference to
>`gameport_register_port'

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.

Re: es1371 compile issue in 2.4.5-ac9

[Alan Olsen]

On Fri, 8 Jun 2001, Keith Owens wrote:

> On Wed, 6 Jun 2001 14:45:10 -0700 (PDT), 
> Alan Olsen <alan@clueserver.org> wrote:
> >I rebuilt from clean source and patch for 2.4.5-ac9 and neglected to add
> >in anything using the joystick.
> >
> >ld -m elf_i386 -T /usr/src/linux/arch/i386/vmlinux.lds -e stext ...
> >	-o vmlinux
> >drivers/sound/sounddrivers.o: In function `es1371_probe':
> >drivers/sound/sounddrivers.o(.text+0x5e5d): undefined reference to
> >`gameport_register_port'
> 
> 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.

alan@ctrl-alt-del.com | 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

Re: temperature standard - global config option?

[José Luis Domingo López]

On Wednesday, 06 June 2001, at 18:06:56 +0200,
Chris Boot wrote:

> Hi,
> 
> > Please, don't.
> > 
> > Use kelvins *0.1, and use them consistently everywhere. This is what
> > ACPI does, and it is probably right.
> 
> 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
>
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

Re: temperature standard - global config option?

[watermodem]

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!


José Luis Domingo López wrote:
> 
> On Wednesday, 06 June 2001, at 18:06:56 +0200,
> Chris Boot wrote:
> 
> > Hi,
> >
> > > Please, don't.
> > >
> > > Use kelvins *0.1, and use them consistently everywhere. This is what
> > > ACPI does, and it is probably right.
> >
> > 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
> >
> 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
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: temperature standard - global config option?

[Pavel Machek]

Hi!

> > Please, don't.
> > 
> > Use kelvins *0.1, and use them consistently everywhere. This is what
> > ACPI does, and it is probably right.
> 
> 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.

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+

Re: temperature standard - global config option?

[J . A . Magallon]

On 06.06 Pavel Machek wrote:
> 
> ACPI is already using 0.1*K, so everything should use that to be
> consistent.
> 								Pavel

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:jamagallon@able.es
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

Re: temperature standard - global config option?

[Philips]

[-- Attachment #1: Type: text/plain, Size: 294 bytes --]

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.

[-- Attachment #2: Card for Philips --]
[-- Type: text/x-vcard, Size: 407 bytes --]

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:philips@iph.to
title:Software Developer
note:(none)
x-mozilla-cpt:;18368
fn:Philips
end:vcard

Re: temperature standard - global config option?

[L. K.]

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



On Thu, 7 Jun 2001, Philips wrote:

> 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.

Re: temperature standard - global config option?

[David Rees]

On Thu, Jun 07, 2001 at 03:20:03PM +0300, L. K. wrote:
> On Thu, 7 Jun 2001, Philips wrote:
> 
> > 	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.
> 
> Why not make it in Celsius ? Is more easy to read it this way.

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

Re: temperature standard - global config option?

[Chris Boot]

Hi,

>>> 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.
>> 
>> Why not make it in Celsius ? Is more easy to read it this way.
> 
> 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.

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
bootc@worldnet.fr

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

Re: temperature standard - global config option?

[Albert D. Cahalan]

Chris Boot writes:

>>>> Kelvins good idea in general - it is always positive ;-)
>>>>
>>>> 0.01*K fits in 16 bits and gives reasonable range.
...
> 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?

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.

Re: temperature standard - global config option?

[Michael H. Warfield]

On Thu, Jun 07, 2001 at 08:03:58PM -0400, Albert D. Cahalan wrote:
> Chris Boot writes:
> 
> >>>> Kelvins good idea in general - it is always positive ;-)
> >>>>
> >>>> 0.01*K fits in 16 bits and gives reasonable range.
> ...
> > 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?
> 
> 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   |  mhw@WittsEnd.com
  (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!

Re: temperature standard - global config option?

[Albert D. Cahalan]

L. K. writes:

> 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.

Re: temperature standard - global config option?

[L. K.]

On Thu, 7 Jun 2001, Albert D. Cahalan wrote:

> Negative temperatures do not really exist.
> 

Are you really sure about this ?



> 
> 
> 
> 
> 

Re: temperature standard - global config option?

[mirabilos {Thorsten Glaser}]

It was posted by L. K. where I now add my 0.02 EUR...
> On Thu, 7 Jun 2001, Albert D. Cahalan wrote:
> > Negative temperatures do not really exist.
> Are you really sure about this ?

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!

Re: temperature standard - global config option?

[Michael H. Warfield]

On Thu, Jun 07, 2001 at 09:30:54PM +0000, mirabilos {Thorsten Glaser} wrote:
> It was posted by L. K. where I now add my 0.02 EUR...
> > On Thu, 7 Jun 2001, Albert D. Cahalan wrote:
> > > Negative temperatures do not really exist.
> > Are you really sure about this ?

> 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).

	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.

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

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (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!

Re: temperature standard - global config option?

[Thomas Speck]

On Thu, 7 Jun 2001, Michael H. Warfield wrote:

> 	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.

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 ?

> 	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.

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

--
Thomas

Re: temperature standard - global config option?

[Chris Boot]

Hi,

> 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.

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
bootc@worldnet.fr

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

Re: temperature standard - global config option?

[Michael H. Warfield]

On Fri, Jun 08, 2001 at 07:33:14PM +0200, Chris Boot wrote:
> Hi,

> > 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.

> 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!

	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.

> -- 
> Chris Boot
> bootc@worldnet.fr

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

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (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!

Re: temperature standard - global config option?

[J . A . Magallon]

On 06.08 Michael H. Warfield wrote:
> 
> 	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.

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:jamagallon@able.es
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

Re: temperature standard - global config option?

[Michael H. Warfield]

On Fri, Jun 08, 2001 at 08:43:06PM +0200, J . A . Magallon wrote:

> On 06.08 Michael H. Warfield wrote:

> > 	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.

> 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.

	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.

> -- 
> J.A. Magallon                           #  Let the source be with you...        
> mailto:jamagallon@able.es
> 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

	Mike
-- 
 Michael H. Warfield    |  (770) 985-6132   |  mhw@WittsEnd.com
  (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!

Re: temperature standard - global config option?

[J . A . Magallon]

On 06.08 Michael H. Warfield wrote:
> 
> 	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.
> 

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:jamagallon@able.es
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

Re: temperature standard - global config option?

[Albert D. Cahalan]

Michael H. Warfiel writes:

> 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.
...
> 	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?

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.

Re: temperature standard - global config option?

[L. K.]

On Fri, 8 Jun 2001, Albert D. Cahalan wrote:

> Michael H. Warfiel writes:
> 
> > 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.
> ...
> > 	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?
> 
> 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,


> 

Re: temperature standard - global config option?

[Albert D. Cahalan]

L. K. writes:
> On Fri, 8 Jun 2001, Albert D. Cahalan wrote:

>> 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.

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.

Re: temperature standard - global config option?

[Chris Boot]

Hi,

> Only the truly stupid would assume accuracy from decimal places.

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
bootc@worldnet.fr

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

Re: temperature standard - global config option?

[H. Peter Anvin]

Followup to:  <B7471019.F9CF%bootc@worldnet.fr>
By author:    Chris Boot <bootc@worldnet.fr>
In newsgroup: linux.dev.kernel
> 
> 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.
> 

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

> 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.

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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: temperature standard - global config option?

[Jonathan Morton]

>  > > Only the truly stupid would assume accuracy from decimal places.
>>
>>  Well then, tell all the teachers in this world that they're stupid, and tell
>>  everyone who learnt from them as well.
>
>*All*?
>
>>  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.
>
>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.

*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:     chromi@cyberspace.org  (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.

Re: temperature standard - global config option?

[Kurt Roeckx]

On Thu, Jun 21, 2001 at 12:18:12PM +0100, Jonathan Morton wrote:
> 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.

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

Re: temperature standard - global config option?

[Michael H. Warfield]

On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote:

> 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.

	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.

> One might provide other numbers to specify accuracy and precision.

	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   |  mhw@WittsEnd.com
  (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!

RE: temperature standard - global config option?

[John Chris Wren]

[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

Re: temperature standard - global config option?

[Albert D. Cahalan]

John Chris Wren writes:

> 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*

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

> 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.

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

Re: temperature standard - global config option?

[H. Peter Anvin]

Followup to:  <200106090352.f593q7M491225@saturn.cs.uml.edu>
By author:    "Albert D. Cahalan" <acahalan@cs.uml.edu>
In newsgroup: linux.dev.kernel
> > 
> > But in spite of all this, you're not really measure the critical
> > temperature, which is junction tempature.  Yes, case tempature has *some*
> 
> There are processors with temperature measurement built right
> into the silicon.
> 

As far as I know, ALL current microprocessors do.

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

Re: temperature standard - global config option?

[James Sutherland]

On 9 Jun 2001, H. Peter Anvin wrote:
> Followup to:  <200106090352.f593q7M491225@saturn.cs.uml.edu>
> By author:    "Albert D. Cahalan" <acahalan@cs.uml.edu>
> In newsgroup: linux.dev.kernel
> > >
> > > But in spite of all this, you're not really measure the critical
> > > temperature, which is junction tempature.  Yes, case tempature has *some*
> >
> > There are processors with temperature measurement built right
> > into the silicon.
>
> As far as I know, ALL current microprocessors do.

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.

Re: temperature standard - global config option?

[Charles Cazabon]

James Sutherland <jas88@cam.ac.uk> wrote:
> 
> The current x86 setup uses a small sensor sitting under the CPU socket.

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                            <linux@discworld.dyndns.org>
GPL'ed software available at:  http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------

Re: temperature standard - global config option?

[Bill Pringlemeir]

>>>>> "MHW" == Michael H Warfield <mhw@wittsend.com> writes:
[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...

Re: temperature standard - global config option?

[L. K.]

On 8 Jun 2001, Bill Pringlemeir wrote:

> 
> >>>>> "MHW" == Michael H Warfield <mhw@wittsend.com> writes:
> [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.  
> 


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 ...


> 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!
> 

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


> regards,
> Bill Pringlemeir.
> 
> This thread keeps going and going and going...

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

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



Regards,

/me

Re: temperature standard - global config option?

[Steffen Persvold]

"L. K." wrote:
> I haven't encountered any CPU with builtin temperature sensors.
> 
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:sp@scali.no     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

Re: temperature standard - global config option?

[Chris Boot]

Hi,

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

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.

>> This thread keeps going and going and going...
> 
> and going, and going ..... and still going .....

and going, and going, and going...

-- 
    .-.         Chris Boot
    /v\      bootc@worldnet.fr
   // \\
  /(   )\    L   I   N   U   X
   ^^-^^    >Phear the Penguin<

Re: temperature standard - global config option?

[Albert D. Cahalan]

Michael H. Warfiel writes:
> On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote:

>> 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.
...
> 	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.

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.

> 	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.

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.

>> One might provide other numbers to specify accuracy and precision.
>
> 	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.

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.

Re: temperature standard - global config option?

[H. Peter Anvin]

Followup to:  <20010608191600.A12143@alcove.wittsend.com>
By author:    "Michael H. Warfield" <mhw@wittsend.com>
In newsgroup: linux.dev.kernel
> 
> 	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.
> 

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
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt

Re: temperature standard - global config option?

[Albert D. Cahalan]

Michael H. Warfiel writes:
> On Fri, Jun 08, 2001 at 05:16:39PM -0400, Albert D. Cahalan wrote:

>> 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.
...
> 	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.

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;
}

Re: temperature standard - global config option?

[H. Peter Anvin]

Followup to:  <200106090800.f5980i101507@saturn.cs.uml.edu>
By author:    "Albert D. Cahalan" <acahalan@cs.uml.edu>
In newsgroup: linux.dev.kernel
> 
> 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.
> 

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

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

Re: temperature standard - global config option?

[Kai Henningsen]

bootc@worldnet.fr (Chris Boot)  wrote on 08.06.01 in <B7471019.F9CF%bootc@worldnet.fr>:

> > Only the truly stupid would assume accuracy from decimal places.
>
> Well then, tell all the teachers in this world that they're stupid, and tell
> everyone who learnt from them as well.

*All*?

> 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.

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

Re: temperature standard - global config option?

[L. K.]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 582 bytes --]

> > Are you really sure about this ?
> 
> 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).

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,




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

Re: temperature standard - global config option?

[john slee]

On Wed, Jun 06, 2001 at 02:27:22PM +0200, David N. Welton wrote:
> 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.

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

Re: temperature standard - global config option?

[J . A . Magallon]

On 06.06 john slee wrote:
> 
> On Wed, Jun 06, 2001 at 02:27:22PM +0200, David N. Welton wrote:
> > 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.
> 
> celsius is probably a sensible default - lots of the world uses it now.
> 

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:jamagallon@able.es
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

Re: temperature standard - global config option?

[Dr. Kelsey Hudson]

On 6 Jun 2001, David N. Welton wrote:

>
> [ 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.

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                                           khudson@ctica.com
 Software Engineer
 Compendium Technologies, Inc                               (619) 725-0771
---------------------------------------------------------------------------

Re: temperature standard - global config option?

[Alan Cox]

> 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.

The spec is farenheit

Re: temperature standard - global config option?

[J . A . Magallon]

On 06.06 Alan Cox wrote:
> > 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.
> 
> The spec is farenheit

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:jamagallon@able.es
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

Re: temperature standard - global config option?

[Paul Fulghum]

> 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

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

Paul Fulghum paulkf@microgate.com
Microgate Corporation www.microgate.com

Re: temperature standard - global config option?

[Harald Arnesen]

"J . A . Magallon" <jamagallon@able.es> writes:

> On 06.06 Alan Cox wrote:
> > The spec is farenheit
> 
> 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.

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.

Re: temperature standard - global config option?

[Alan Cox]

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

/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

Re: temperature standard - global config option?

[David N. Welton]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

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

> /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.

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.
 
> Newer API's should probably use celcius/kelvin

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/

Re: temperature standard - global config option?

[Pavel Machek]

Hi!

> > 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.
> 
> The spec is farenheit

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+

Re: temperature standard - global config option?

[Alan Cox]

> > The spec is farenheit
> What specs?

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

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

For new stuff - for ACPI etc definitely