/ Forside / Teknologi / Operativsystemer / Linux / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Linux
#NavnPoint
o.v.n. 11177
peque 7911
dk 4814
e.c 2359
Uranus 1334
emesen 1334
stone47 1307
linuxrules 1214
Octon 1100
10  BjarneD 875
CPU-temperatur...
Fra : Rander


Dato : 04-08-05 18:27

Nogle vil måske råbe "off-topic" ud fra subject, men der er nu noget i
det...

Jeg har en æske der kører Debian, med en hjemmebygget 2.6.8-kerne.

I går røg der en RAM-blok i serveren, så jeg pillede den ud og lod serveren
køre videre med den anden blok alene. Dette indebar selvfølgelig en
nedlukning og efterfølgende boot...

I dag var jeg så nede og få byttet blokken, kommer hjem og lukker maskinen
ned, sætter blokken i og booter op igen...

Så kommer det jeg er en smule nervøs over: Lige pludselig er temperaturen i
CPU-kernen fordoblet! I følge BIOS ligger temperaturen på ca. 50 grader
(den er vel idle når den står i BIOS-skærmens Hardare Monitor?), og når
Debian er bootet op viser sensors at CPU'en er ca. 71 grader - det synes
jeg er ret voldsomt, specielt at den tilsyneladende skulle være steget 20
grader under en boot-sekvens der tager max. 30 sekunder...

MRTG måler temperaturen til 73 grader - også over en 5-minutters periode
hvor sensors konstant har vist 71-71.5 grader...

MRTG-siden for temperaturen kan ses på <http://mrtg.rander.dk/temp.html> -
det skulle være ret tydeligt at den nye RAM-blok kom i ved 16-tiden i dag.
Chassis-temperaturen er "kun" steget 1-2 grader, som det vist også
fremgår...

Hvad bør man gå ud fra er mest præcist - BIOS eller lm-sensors? Kan
udskiftning af en RAM-blok alene forårsage en så voldsom
temperatur-forøgelse? Alle blæsere kører, ifølge MRTG med uændret hastighed
(på de to den kan måle på, CPU- og PSU-fans)...

Hvis det har nogen betydning kører maskinen "sensors version 2.9.1 with
libsensors version 2.9.1".

--
Lars Rander ** Pil ikke ved min adresse ** :(){ :&:& };:
http://rander.dk (temporarily down!)

Reeza tror ikke på Gud, han tror på Allan. (Kate, 6 år)


 
 
Kasper Dupont (05-08-2005)
Kommentar
Fra : Kasper Dupont


Dato : 05-08-05 07:03

Rander wrote:
>
> I følge BIOS ligger temperaturen på ca. 50 grader
> (den er vel idle når den står i BIOS-skærmens Hardare Monitor?),

Nej, det skal du ikke regne med. BIOS kan typisk
ikke finde ud af at halte CPUen når den ikke er i
brug. Så så længe du er i BIOS opsætningen kan
CPUen sagens stå og busywaite på tastaturinput.
(Det samme gælder i øvrigt DOS og bootloadere,
som også bruger BIOS til tastaturinput.)

Jeg har på et tidspunkt på en maskine prøvet at
reboote efter den havde stået idle i Linux længe.
Da jeg gik ind i BIOS menuens hardware monitor
var temperaturen lavere end den normalt er men
begyndte så langsomt at stige.

>
> Hvad bør man gå ud fra er mest præcist - BIOS eller lm-sensors?

Man burde kunne gå ud fra, at BIOS ved, hvordan
sensorerne kan fortolkes. På den anden side kan
jeg godt forestille mig, at lm-sensors ikke ved
præcise hvordan samtlige sensorer på alle mulige
slags hardware skal fortolkes. Så jeg ville nok
stole mest på aflæsningerne i BIOS. Ved du om det
er den samme sensor, de får oplysningerne fra?

Du kunne prøve at reboote nogle gange for at
aflæse temperaturen skiftevis med lm-sensors og
BIOS. Jeg tror nemlig ikke temperaturen kan
svinge så hurtigt op og ned.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

Kent Friis (05-08-2005)
Kommentar
Fra : Kent Friis


Dato : 05-08-05 08:22

Den Fri, 05 Aug 2005 08:02:49 +0200 skrev Kasper Dupont:
> Rander wrote:
>>
>> Hvad bør man gå ud fra er mest præcist - BIOS eller lm-sensors?
>
> Man burde kunne gå ud fra, at BIOS ved, hvordan
> sensorerne kan fortolkes. På den anden side kan
> jeg godt forestille mig, at lm-sensors ikke ved
> præcise hvordan samtlige sensorer på alle mulige
> slags hardware skal fortolkes. Så jeg ville nok
> stole mest på aflæsningerne i BIOS. Ved du om det
> er den samme sensor, de får oplysningerne fra?

Jeg mener endda de direkte skriver i dokumentationen at man skal
sammenligne de to for at finde ud af hvad sensor-værdien skal ganges
med for at få temperaturen i grader.

> Du kunne prøve at reboote nogle gange for at
> aflæse temperaturen skiftevis med lm-sensors og
> BIOS. Jeg tror nemlig ikke temperaturen kan
> svinge så hurtigt op og ned.

Op kan den godt (bare se den der AMD uden køler video), men ned vil
jeg give dig ret.

Mvh
Kent
--
Hard work may pay off in the long run, but lazyness pays off right now.

Rander (05-08-2005)
Kommentar
Fra : Rander


Dato : 05-08-05 12:16

Fri, 05 Aug 2005 08:02:49 +0200 brugte Kasper Dupont 38 linier på at
fortælle dette til dk.edb.system.unix:

>> Hvad bør man gå ud fra er mest præcist - BIOS eller lm-sensors?
>Man burde kunne gå ud fra, at BIOS ved, hvordan
>sensorerne kan fortolkes. På den anden side kan
>jeg godt forestille mig, at lm-sensors ikke ved
>præcise hvordan samtlige sensorer på alle mulige
>slags hardware skal fortolkes. Så jeg ville nok
>stole mest på aflæsningerne i BIOS. Ved du om det
>er den samme sensor, de får oplysningerne fra?

Nej, jeg ved ikke hvilken sensor BIOS får oplysningerne fra, men...

>Du kunne prøve at reboote nogle gange for at
>aflæse temperaturen skiftevis med lm-sensors og
>BIOS. Jeg tror nemlig ikke temperaturen kan
>svinge så hurtigt op og ned.

....her bliver det virkelig interessant: Jeg lagde mærke til, at lm-sensors
brugte en thermistor-sensor på CPU'en, når den aflæste temperaturer på
71-71 grader. Efter et par reboots aflæste den de sædvanlige 33-35 grader -
men nu på diode-sensor, uden at der er ændret noget som helst i
opsætningen!

Men det er jo tydeligt nok at de to aflæsninger ikke passer særlig godt med
BIOS-aflæsningen. Jeg ved ikke engang om processoren KAN haltes, som du
skrev noget om...

Fra /proc/cpuinfo:

vendor_id : GenuineIntel
cpu family : 15
model : 2
model name : Intel(R) Celeron(R) CPU 2.40GHz
stepping : 9
cpu MHz : 2327.029
cache size : 128 KB
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
bogomips : 4554.75

Især flagene kan jeg ikke lige genneskue - jeg kender kun acpi, mmx, sse og
sse2...

--
Lars Rander ** Pil ikke ved min adresse ** :(){ :&:& };:
http://rander.dk (temporarily down!)

Lev dit liv, så dine venner kan forsvare dig, men ikke behøver at gøre det. (Arnold H. Glasgow)


Kent Friis (05-08-2005)
Kommentar
Fra : Kent Friis


Dato : 05-08-05 12:50

Den Fri, 05 Aug 2005 13:16:18 +0200 skrev Rander:
>
> Men det er jo tydeligt nok at de to aflæsninger ikke passer særlig godt med
> BIOS-aflæsningen. Jeg ved ikke engang om processoren KAN haltes, som du
> skrev noget om...

Medmindre du har "hlt_bug: yes", så kan den som minimum bruge
hlt-kommandoen. ACPI powersave levels giver nok mere, men det er
vist primært på bærbare CPU'er der er så meget at hente.

> Fra /proc/cpuinfo:
>
> vendor_id : GenuineIntel
> cpu family : 15
> model : 2
> model name : Intel(R) Celeron(R) CPU 2.40GHz
> stepping : 9
> cpu MHz : 2327.029
> cache size : 128 KB
> fpu : yes
> fpu_exception : yes
> cpuid level : 2
> wp : yes
> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
> cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid
> bogomips : 4554.75
>
> Især flagene kan jeg ikke lige genneskue - jeg kender kun acpi, mmx, sse og
> sse2...

fpu: floating point unit.
tsc: vist nok noget med en timer.
pae: page address extension, 48 bit adresse-bus, 64 GB RAM i stedet for
de 4 GB der er max med 32 bit.
apic: en chip der har noget med i/o at gøre tror jeg nok.
mtrr: memory type range registers.
cmov: jeg tror næsten det er en speciel mov instruktion

Mvh
Kent
--
Hard work may pay off in the long run, but lazyness pays off right now.

Kasper Dupont (05-08-2005)
Kommentar
Fra : Kasper Dupont


Dato : 05-08-05 13:47

Kent Friis wrote:
>
> Medmindre du har "hlt_bug: yes", så kan den som minimum bruge
> hlt-kommandoen.

Ja, HLT instruktionen har så vidt jeg ved eksisteret lige
siden 8086, så bortset lige fra de få CPU modeler med bugs,
så kan de alle haltes. Selvom CPUen kan haltes kan det godt
alligevel være problematisk i nogle setups, f.eks. har jeg
en maskine, hvor det forårsager støj på lydkortet. Men så
kan man jo heldigvis slå halting fra.

> ACPI powersave levels giver nok mere, men det er
> vist primært på bærbare CPU'er der er så meget at hente.

Tja, jeg ved ikke med den maskine jeg prøvede på. Men så
vidt jeg husker brugte jeg en kerne uden ACPI support, så
det har nok bare været en ganske almindelig HLT instruktion,
der gjorde forskellen.

Jeg har også engang observeret, at et lille DOS program jeg
skrev til at køre på en gammel Toshiba laptop gav væsentligt
mindre aktivitet på blæseren hvis jeg indsatte et par
strategiske HLT instruktioner.

>
> fpu: floating point unit.
> tsc: vist nok noget med en timer.

Korrekt.

> pae: page address extension, 48 bit adresse-bus, 64 GB RAM i stedet for
> de 4 GB der er max med 32 bit.

Er det ikke kun 36 bits? Det med de 48 kan jo heller ikke
passe, for så mange bits har der ikke været til overs i page
tabel indgangene så længe man kørte med 4KB pages. Men måske
det kunne lade sig gøre med 2/4MB pages.

> apic: en chip der har noget med i/o at gøre tror jeg nok.

Advanced Programable Interrupt Controller. Den erstatter
den gamle 8259 kompatible Programable Interrupt Controller.
Forskellene er vist, at den nye er væsentligt mere effektiv
til nogle operationer samt at den kan håndtere flere
interrupt linier og er bedre til multiprocesser systemer.

> mtrr: memory type range registers.

Hvilket vil sige, at man kan fortælle CPUen hvordan
forskellige dele af det fysiske adresserum skal caches.
(Jeg ved ikke om mtrr har indflydelse på andet end caching).
Det er vist ret væsentligt at grafikram og systemram skal
caches på forskellige måder.

> cmov: jeg tror næsten det er en speciel mov instruktion

Jeg er ikke sikker, men jeg tror nok at den kan noget med at
kopiere data mellem RAM områder og tage særligt højde for
caching, mens den gør det.

--
Kasper Dupont -- der bruger for meget tid på usenet.
Note to self: Don't try to allocate 256000 pages
with GFP_KERNEL on x86.

Kent Friis (05-08-2005)
Kommentar
Fra : Kent Friis


Dato : 05-08-05 13:55

Den Fri, 05 Aug 2005 14:47:07 +0200 skrev Kasper Dupont:
> Kent Friis wrote:
>
>> pae: page address extension, 48 bit adresse-bus, 64 GB RAM i stedet for
>> de 4 GB der er max med 32 bit.
>
> Er det ikke kun 36 bits? Det med de 48 kan jo heller ikke
> passe, for så mange bits har der ikke været til overs i page
> tabel indgangene så længe man kørte med 4KB pages. Men måske
> det kunne lade sig gøre med 2/4MB pages.

4, 8, 16, 32, 64 GB - 4 bits, jo, det må være 36.

>> apic: en chip der har noget med i/o at gøre tror jeg nok.
>
> Advanced Programable Interrupt Controller. Den erstatter
> den gamle 8259 kompatible Programable Interrupt Controller.
> Forskellene er vist, at den nye er væsentligt mere effektiv
> til nogle operationer samt at den kan håndtere flere
> interrupt linier og er bedre til multiprocesser systemer.

Den er krævet på multiprocessor, i hvert fald under Linux.

>> mtrr: memory type range registers.
>
> Hvilket vil sige, at man kan fortælle CPUen hvordan
> forskellige dele af det fysiske adresserum skal caches.
> (Jeg ved ikke om mtrr har indflydelse på andet end caching).
> Det er vist ret væsentligt at grafikram og systemram skal
> caches på forskellige måder.

Caching var også lige det jeg kunne huske - specielt var der en bug
på AMD-CPU'er, hvor man når de overlapper kunne skrive uden cache,
og dermed uden at cachen blev opdateret, og så læse med cache og
få den gamle værdi. Intel CPU'erne opdaterede vist cachen selvom den
ikke blev brugt ved læsning.

>> cmov: jeg tror næsten det er en speciel mov instruktion
>
> Jeg er ikke sikker, men jeg tror nok at den kan noget med at
> kopiere data mellem RAM områder og tage særligt højde for
> caching, mens den gør det.

Lyder sandsynligt, der er jo ikke flag for alle de normale
mov-instruktioner

Mvh
Kent
--
Hard work may pay off in the long run, but lazyness pays off right now.

Thomas Damgaard Niel~ (05-08-2005)
Kommentar
Fra : Thomas Damgaard Niel~


Dato : 05-08-05 20:10

Kasper Dupont wrote:
> Jeg har også engang observeret, at et lille DOS program jeg
> skrev til at køre på en gammel Toshiba laptop gav væsentligt
> mindre aktivitet på blæseren hvis jeg indsatte et par
> strategiske HLT instruktioner.

Hvordan giver man maskine HLT-instruktioner fra f.eks. et C-program?

--
Thomas Damgaard Nielsen
http://thomasdamgaard.dk/
Light travels faster than sound.
This is why some people appear bright until you hear them speak.

Thorbjoern Ravn Ande~ (05-08-2005)
Kommentar
Fra : Thorbjoern Ravn Ande~


Dato : 05-08-05 20:31

Thomas Damgaard Nielsen <tdn.usenet@gmail.com> writes:

> Hvordan giver man maskine HLT-instruktioner fra f.eks. et C-program?

Ved at indsætte en stump maskinkode i dit C-program. Hvordan dette
gøres afhænger af C-compileren.

Bemærk at det kun vil have virkning på systemer der ikke kører
multitaskning. På multitasking systemer skal man i stedet sige til
operativsystemet at man ikke behøver mere CPU-tid lige nu.

--
Thorbjørn Ravn Andersen


Thomas Damgaard Niel~ (06-08-2005)
Kommentar
Fra : Thomas Damgaard Niel~


Dato : 06-08-05 00:47

Thorbjoern Ravn Andersen wrote:
> >Hvordan giver man maskine HLT-instruktioner fra f.eks. et C-program?
>
> Ved at indsætte en stump maskinkode i dit C-program. Hvordan dette
> gøres afhænger af C-compileren.
>
> Bemærk at det kun vil have virkning på systemer der ikke kører
> multitaskning. På multitasking systemer skal man i stedet sige til
> operativsystemet at man ikke behøver mere CPU-tid lige nu.

Ok. Tak for informationen. Glemte lige at det fungerede sådan i
multitasking-systemer. Så bliver det jo taget sig af i min kode :)

--
Thomas Damgaard Nielsen
http://thomasdamgaard.dk/
Light travels faster than sound.
This is why some people appear bright until you hear them speak.

Peter Makholm (05-08-2005)
Kommentar
Fra : Peter Makholm


Dato : 05-08-05 14:13

Kasper Dupont <kasperd@daimi.au.dk> writes:

>> cmov: jeg tror næsten det er en speciel mov instruktion
>
> Jeg er ikke sikker, men jeg tror nok at den kan noget med at
> kopiere data mellem RAM områder og tage særligt højde for
> caching, mens den gør det.

Conditional MOVe. I en række tilfælde erstatter det en
branch-operation, men det bruges vist også til at implementerer
semaforer med.

glibc har (haft?) et problem med at den antog at en 686-cpu
understøttede cmov, men nogle cpu'er kaldte sig selv 686 uden at
understøtte cmov (via c3, bland andet).

--
Peter Makholm | One thing you do is prevent good software from
peter@makholm.net | being written. Who can afford to do professional
http://hacking.dk | work for nothing?
| -- Bill Gates

Peter Makholm (05-08-2005)
Kommentar
Fra : Peter Makholm


Dato : 05-08-05 14:17

Peter Makholm <peter@makholm.net> writes:

> glibc har (haft?) et problem med at den antog at en 686-cpu
> understøttede cmov, men nogle cpu'er kaldte sig selv 686 uden at
> understøtte cmov (via c3, bland andet).

Rettelse, det var ikke glibc's skyld. Det var gcc der spyttede
cmov-operationer ud når man bad den oversætte til -march=686.

--
Peter Makholm | I have no caps-lock but I must scream...
peter@makholm.net | -- Greg
http://hacking.dk |

Rasmus Bøg Hansen (05-08-2005)
Kommentar
Fra : Rasmus Bøg Hansen


Dato : 05-08-05 09:07

Kent Friis <nospam@nospam.invalid> hit the keyboard.
Afterwards the following was on the screen:

> Den Fri, 05 Aug 2005 08:02:49 +0200 skrev Kasper Dupont:
>> Rander wrote:
>>>
>>> Hvad bør man gå ud fra er mest præcist - BIOS eller lm-sensors?
>>
>> Man burde kunne gå ud fra, at BIOS ved, hvordan
>> sensorerne kan fortolkes. På den anden side kan
>> jeg godt forestille mig, at lm-sensors ikke ved
>> præcise hvordan samtlige sensorer på alle mulige
>> slags hardware skal fortolkes. Så jeg ville nok
>> stole mest på aflæsningerne i BIOS. Ved du om det
>> er den samme sensor, de får oplysningerne fra?
>
> Jeg mener endda de direkte skriver i dokumentationen at man skal
> sammenligne de to for at finde ud af hvad sensor-værdien skal ganges
> med for at få temperaturen i grader.

Det skriverer de ganske rigtigt. Jeg har dog haft held nogle gange med
at google efter det pågældende bundkort, da jeg skulle lave mig en
sensors.conf.

>> Du kunne prøve at reboote nogle gange for at
>> aflæse temperaturen skiftevis med lm-sensors og
>> BIOS. Jeg tror nemlig ikke temperaturen kan
>> svinge så hurtigt op og ned.
>
> Op kan den godt (bare se den der AMD uden køler video), men ned vil
> jeg give dig ret.

Det er så også et noget ekstremt tilfælde

Nuvel, når temperaturen først er stabiliseret efter boot, varierer
temperaturen ikke længere så hurtigt. Jeg ville dog genstarte for at
sammenligne en god del gange.

/Rasmus

--
-- [ Rasmus "Møffe" Bøg Hansen ] ---------------------------------------
No, no, stop! Now I got coffee in my keyboard!
----------------------------------------------[ moffe at zz9 dot dk ] --

Søg
Reklame
Statistik
Spørgsmål : 177552
Tips : 31968
Nyheder : 719565
Indlæg : 6408847
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste