Temperaturanzeige Intel E8400 viel zu hoch?

HHF

Neuling
Thread Starter
Mitglied seit
21.02.2007
Beiträge
79
Hallo Leute,

es ist ja mittlerweile bekannt, dass irgendetwas mit der Temperaturdiode bei den Penryn Prozessoren nicht stimmt. Mich würde jedoch interessieren, ob ihr ähnliche Ergebnisse messt.

Ich habe ein Board mit P35-Chipsatz (MSI-Neo2 P35) und hatte bisher einen Intel E6300. Gekühlt durch einen Scythe Ninja Rev. B. Meine Temperatur im Idle-Betrieb war immer so um die 26 °C und unter Last (übertaktet auf 3,22 GHz) maximal 56 °C. Ich denke, dass sind realistische Werte.

Nun habe ich auf den Intel E8400 gewechselt. Im Idle-Betrieb zeigt mir RMClock nun 40 °C (!!) an und unter Last (übertaktet auf 3,8 GHz) schon 65 °C! Der Rechner läuft trotzdem stabil und der Lüfter ist zu 100% richtig montiert. Der Scythe fühlt sich unter Last handwarm an, aber nicht heiß.

Heißt das jetzt, dass ich 14 °C abziehen muss und der Intel E8400 hat unter Last in Wahrheit nur 51 °C?? Oder wie ist der Wert zu interpretieren? Sind bei Euch die Werte ähnlich?

Gruß
HHF
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Also ich liege selbst bei 4,4GHz und 1,5V unter deinen Werten (Last 63°C), wobei mein Scythe Mine ja eher schlechter ist als der Ninja. Nimm mal die neuste Coretemp version.
 
die sensoren zeigen irgendeinen müll - du kannst also nicht einfach einen fixwert abziehen.

wer sagt dir denn, daß die sensoren brav mit jedem grad, um das die temperatur steigt, auch genau ein grad mitgehen?

solange kein c1-stepping da ist, sind temperaturangaben aus den cpu-registern für die tonne (und für mich immer wieder ein anlass zum lachen... m4rvin wird meistens kotzen ;) )

-> selber messen oder über die mainboard-diode.
 
@gbm31: correct... ausserdem hat Intel eigentlich die Coretemps gar nicht für uns zum Auslesen gedacht... deshalb kann man auch keine Garantieansprüche geltend machen... solange das dingens gut läuft ist es doch auch egal - die CPU wird sich eh schon melden, wenns nicht mehr primestable läuft!
 
Bei der E8x00 ist das mit den Temps so eine Sache. Bei den Programmen kommt es immer darauf an, was für eine TJ.Max angenommen wird. Bei CoreTemp sind es (glaube ich) 105°C, bei RealTemp dann nur 95°C und schon hast du 10°C Unterschied bei den Kerntemperaturen.

Im Grunde macht es Intel einem doch einfach. Warum versteift man sich immer auf die angegebene Temperatur der Kerne? Warum orientiert man sich nicht einfach mal an den Delta-Werten? Da erkennt man zumindest, ob noch genug Spielraum zum Übertakten vorhanden ist und ob die Hardware kurz vorm Überhitzen ist oder alles im grünen Bereich läuft.

Diskussionen über die angezeigte Temperatur der Programme fallen dann aus.
 
Das gleiche habe ich bei meinem Bruder beobachtet. E8400 @ 1,35V bei 4GHz. Gekühlt wird er mit nem TR HR-01 Plus und erreicht unter Prime gerne 70°C obwohl der Kühler sowas von kalt ist (mitten drin 33°C). Die Angaben kann man getrost vergessen, genau wie die meines E4400. Das Ding läuft und fertig, zu heiß kann es bei den heutigen Kühlermonstern garnicht sein, wenn man sich mal die kleinen Boxed kühler anschaut.
 
Kann man so auch nicht pauschalisieren. Wenn du mit den Boxed-Kühler übertaktest und auch noch an der Spannung rumschraubst, kannst du schnell in den Bereich kommen, an dem sich die CPU verabschiedet, bzw. sich der Rechner abschaltet oder die CPU zu Throtteln beginnt.

Deswegen schreibe ich ja, nicht auf die Temps verlassen, sondern sich die Delta-Werte anzeigen lassen.
 
Bei meinem 8500er treten öfters physikalische Wunder auf... er is manchmal kühler als das Wasser der Wasserkühlung^^
 
Zuletzt bearbeitet:
Bei CoreTemp kann man es in den Optionen einstellen und bei RealTemp werden sie direkt mit angezeigt.
 
Bei mir (E8400@3,7ghz) liegen die delta-werte bei 62° im idle. Ist das in Ordnung? Was bedeuten die Delta-werte denn eigentlich?
 
nochmal: es ist nicht mal gegeben, daß die cpu-sensoren richtig skalieren.

was ist es denn wert, daß ihr ein delta von 40°k angezeigt bekommt, wenn jedes dieser grade nur realen 0.73845°k entspricht? (oder 2.34556°k...?)


nur mal als beispiel:

bei 21°c raumtemperatur liest coretemp 49°c für beide cores meines 8200 @ 1.3v (bios) im idle aus (kein c1e/eist).

der 92er xigmatek ist dabei grade mal mit 330 rpm angelaufen, nachdem der vistaboot incl. firefox-start komplett passiv von statten gingen, da das mainboard keinen anlass sah, den cpu-lüfter anzuwerfen.

die mainboard-diode (everest kann die auslesen) spukt dabei 24-25°c aus.


unter 100% auslastung (prime z.b.) zeigt coretemp für beide cores 63°c an.

der xigmatek dreht gemütlich mit 750rpm. die mainboarddiode hab ich grade leider nicht mehr im kopf.

würde ich nur das coretemp-delta betrachten, ergäben sich grade mal 14°k.

ist irgendeine der coretemp-angaben plausibel? für mich keine.


ich vertraue der mainboard-diode, die meinen lüfter regelt - der hat nach oben spielraum bis 2700prm... ;)
 
Zuletzt bearbeitet:
@Urmel2k

Idle-Werte sind doch irrelevant. Interessant sind die Werte unter Last. Im Idle wird keine CPU Probleme bekommen, sofern der Lüfter vernünftig verbaut ist.

@gbm31
Die Mainboard-Diode hat nichts mit der CPU und nichts mit der NB zu tun. Was du da angezeigt bekommst, ist die allgemeine Temperatur des Mobos. Kein Wunder, dass der CPU-Lüfter darauf nicht reagiert, der richtet sich nämlich nach der CPU-Temp, die von einer analogen Diode ausgelesen wird. Die Kerne hingegen werden von einer digitalen, sehr viel genaueren Diode ausgelesen. Wenn du die CPU-Temperatur meinst, dann solltest du das auch so schreiben, da es sonst verwirrend sein kann, da es auch eine Mainboardtemperatur gibt.

Wenn CoreTemp bei dir unter Last 63°C ausgibt verstehe ich nicht, wie du da auf einen Delta-Wert von 14°K (Kelvin?) kommst. Das wären -259.15°C. Selbst 14°C würden nicht stimmen. Angenommen die von CoreTemp angezeigte TJunction von 105°C würde stimmen, so würde der Delta-Wert -42°C anzeigen.

Das wäre durchaus plausibel, selbst wenn dein Lüfter nur mit 750rpm dreht.

Das endet dann darin, dass ich deiner ganzen Ausführung nicht folgen kann.
(Ich mag deine Ausführungen auch einfach nur falsch verstanden haben, wenn dem so sein sollte, dann bitte ich um einer genauere Erläuterung.)
 
Zuletzt bearbeitet:
@gbm31
Die Mainboard-Diode hat nichts mit der CPU und nichts mit der NB zu tun. Was du da angezeigt bekommst, ist die allgemeine Temperatur des Mobos. Kein Wunder, dass der CPU-Lüfter darauf nicht reagiert, der richtet sich nämlich nach der CPU-Temp, die von einer analogen Diode ausgelesen wird. Die Kerne hingegen werden von einer digitalen, sehr viel genaueren Diode ausgelesen.


aua. :fresse:

ich rede von der mainboarddiode für die cpu-temperatur.

von nichts anderem.

und die steuert den cpu-fan-anschluss.

(wär ja auch saublöd von den mainboardherstellern, den cpu-lüfter von einem sensor zwischen den steckkarten steuern zu lassen - dort wird nämlich die sog. mainboard- oder systemp gemessen...)


Wenn CoreTemp bei dir unter Last 63°C ausgibt verstehe ich nicht, wie du da auf einen Delta-Wert von 14°K (Kelvin?) kommst. Das wären -259.15°C. Selbst 14°C würden nicht stimmen. Angenommen die von CoreTemp angezeigte TJunction von 105°C würde stimmen, so würde der Delta-Wert -
42°C anzeigen.
Das wäre durchaus plausibel, selbst wenn dein Lüfter nur mit 750rpm dreht.


eine differenz (ein delta) ist keine absoluttemperatur. ;)

ich meinte das delta zwischen idle und last-temperatur: 63°c - 49°c = 14°c oder k. (ich bin techniker -> k)

ich hab mich evtl. missverständlich ausgedrückt - coretemp bezeichnet den zahlenwert, der aus dem entsprechenden cpu-register ausgelesen wird, als "delta".
und berechnet einfach tjunction (der wert wird auch aus einem register ausgelesen) - "delta" = coretemp.

was jetzt der vorteil sein soll, sich von coretemp die "delta"-werte statt den coretemps anzeigen zu lassen, erschließt sich mir nicht.

auf jeden fall sind bei den c0-wolfdales die werte in den registern, die als "delta" bezeichnet werden, überhaupt nicht zuverlässig.


Das endet dann darin, dass ich deiner ganzen Ausführung nicht folgen kann.
(Ich mag deine Ausführungen auch einfach nur falsch verstanden haben, wenn dem so sein sollte, dann bitte ich um einer genauere Erläuterung.)


jetzt klarer?
 
Zuletzt bearbeitet:
Der Vorteil sich die Delta-Werte anzeigen zu lassen liegt doch auf der Hand. Unabhängig von der vom Programm vorgegebenen TJunction (bei der ich bisher auch angenommen habe, dass sie aus dem Register ausgelesen wird, da dies auch auf der HP von CoreTemp steht), wird zumindest der korrekte Abstand zur maximal zulässigen Kerntemperatur angezeigt. Man erkennt also recht schnell, ob man nah am Maximum ist oder aber weit davon entfernt.

Zur TJunction:
Wie ich bereits geschrieben habe, war ich auch der Meinung, dass die TJunction wohl aus dem Register ausgelesen wird. Auf der Seite von CoreTemp wird das zumindest so geschrieben. Andererseits gibt es im Forum von CoreTemp einen Thread, in dem eben dies dementiert wird. Ob sie nun ausgelesen werden kann, ist zweifelhaft, fest steht aber, dass der Delta-Wert die einzige Möglichkeit ist, die Kerntemperatur korrekt zu interpretieren. Der ist nämlich bei jedem Programm gleich (logisch, wird ja durch die digitalen Dioden übermittelt und nur ausgelesen).

Nimmt Programm A nun also eine TJunction von 105°C an, Programm B aber 95°C so ergibt sich bei einem Delta-Wert von -25°C folgendes Bild:

Programm A: 105°C - 25°C = 80°C (Angezeigte Temperatur der Kerne)
Programm B: 95°C - 25°C = 70°C (Angezeigte Temperatur der Kerne).

Hier ist nun das Problem, was immer wieder auftaucht. Welche Temperatur ist richtig?

Solange niemand den wirklichen Wert der TJunction kennt, bleibt dies ein Rätselraten und man fährt besser, in dem man sich die Delta-Werte anzeigen lässt.

Auf die CPU-Temperatur, die über analoge Sensoren des Mobo-Herstellers ausgelesen werden, würd ich mich am wenigsten verlassen. Problem ist, dass diese oftmals mit verschiedenen Bios-Versionen neu justiert werden. Oftmals hat man sogar das Problem, dass die CPU-Temps völlig realitätsfremd sind. Was häufig vorkommt ist das Problem, dass die CPU-Temps höher sind, als die Temps der Kerne. Das geht natürlich nicht, wobei das für die Steuerung des CPU-Lüfters natürlich "ideal" ist. Dieser dreht so nämlich auf und versucht das ganze auf eine angemessenen Temperatur zu drücken. Problem hier ist dann nur, dass der CPU-Lüfter unter Umständen sehr laut werden kann und unnötig so hochtourig läuft.

Noch zu deinem letzten Satz. Werte in den Registern, die als "Delta" bezeichnet werden?
Da gibt es keine Werte in den Registern. Jeder Kern verfügt über einen eigenen Digitalen Sensor. Dieser meldet einen Delta-Wert, der über das Register der CPU ausgelesen werden kann. Bei dir klang es so, als wenn diese Werte im Register der CPU liegen und nicht an das Register übergeben werden müssen.

Warum sollen diese Werte nicht zuverlässiger sein, als die Werte der Quads? Die Temps scheinen ja zu stimmen und ein Quad besteht doch aus 2 Wolfdale Dual-Cores!?
 
...Unabhängig von der vom Programm vorgegebenen TJunction (bei der ich bisher auch angenommen habe, dass sie aus dem Register ausgelesen wird, da dies auch auf der HP von CoreTemp steht)...

lies nochmal, was in meinem post steht, wo die tjunction herkommt... ;)

...
Zur TJunction:
Wie ich bereits geschrieben habe, war ich auch der Meinung, dass die TJunction wohl aus dem Register ausgelesen wird. Auf der Seite von CoreTemp wird das zumindest so geschrieben. Andererseits gibt es im Forum von CoreTemp einen Thread, in dem eben dies dementiert wird. Ob sie nun ausgelesen werden kann, ist zweifelhaft, fest steht aber, dass der Delta-Wert die einzige Möglichkeit ist, die Kerntemperatur korrekt zu interpretieren. Der ist nämlich bei jedem Programm gleich (logisch, wird ja durch die digitalen Dioden übermittelt und nur ausgelesen).

das liegt daran, daß im entsprechenden register nicht "105°c" stehen muss, sondern irgendein 7-8bit wert, der dann über eine tabelle "übersetzt" werden kann.

je nach cpu könnte es verschiedene tabellen geben, da ist der programmierer gefragt.

(ich habe mich mit dem coretemp-progammierer und der amd-dokumentation zu beginn der amd-e-stepping-zeit sehr lange auseinandergesetzt, da dort ein ähnliches register von amd kurzerhand für was ganz anderes hergenommen wurde und die sensoren bis zu einem bestimmten stepping gar nicht kalibriert waren...)

Noch zu deinem letzten Satz. Werte in den Registern, die als "Delta" bezeichnet werden?
Da gibt es keine Werte in den Registern. Jeder Kern verfügt über einen eigenen Digitalen Sensor. Dieser meldet einen Delta-Wert, der über das Register der CPU ausgelesen werden kann. Bei dir klang es so, als wenn diese Werte im Register der CPU liegen und nicht an das Register übergeben werden müssen.


die sensoren geben ebenfalls nicht "45°c" aus, sondern wieder irgendwas 7-8 bittiges, was evtl. wieder "übersetzt" werden muss...

z.b., weil coretemp wie gesagt einfach tjunction - delta (das ist der wert, der die ditigalen sensoren ins register schreiben) als core-temperatur ausgibt.

intel kalibriert die sensoren eigentlich gut - auf die ausgegebenen werte konnte man sich bisher verlassen.

Warum sollen diese Werte nicht zuverlässiger sein, als die Werte der Quads? Die Temps scheinen ja zu stimmen und ein Quad besteht doch aus 2 Wolfdale Dual-Cores!?


weil beim co-stepping ein fehler aufgetreten ist, den intel selbst dokumentiert hat? ... :rolleyes:




noch was zur absoluten glauben an registerwerte: so, wie es zur zeit bei intel ausgewertet wird, gibt es keine temperaturen unter 0°c - erzähl das mal den kompressorkühlern, die meist 20-40°k drunter liegen...
 
Zuletzt bearbeitet:
Hallo, muß jetzt auch mal meine leidigen Erfahrungen mitteilen. Die Dioden des 8400 werden anscheinend von Coretemp völlig flasch ausgelesen / sind schon defekt. Ich habe zwei verschiedene CPUs probiert, komischerweise bei beiden derselbe Müll. Im Idle@default V-Core (rund 1,17V) gibt Coretemp bereits 50°C aus auf beiden Kernen, daß bei 24°C Wassertemperatur. Stelle ich den Multi auf 6 bei FSB 240 (rund 1400MHz) und 0,84V zeigt Coretemp bereits 49°C an im Idle. Beim zweiten Prozzi exakt das Gleiche. Unter Last wandern die Temps dann auch locker auf 68°C lt. Coretemp.

WLP und Sitz des Kühlers mehrmals gececkt, der HS ist auch nicht krumm, daran leigt es nicht.
Jetzt kommts:
Das wirklich Kuriose ist allerdings, das andere User im Forum mit exakt derselben Batch (Q807) völlig plausible Coretemp-Werte beim selben Board angezeigt bekommen, das ist etwas, was mich sehr wundert!!!!

Wie ist das zu erklären?
 
So, hab jetzt noch mal ein wenig nach dem angeblichen Problem mit den Sensoren beim C0-Stepping geschaut.

Das einzige was ich dazu gefunden habe war:

[...]
AW30. Programming the Digital Thermal Sensor (DTS) Threshold May Cause
Unexpected Thermal Interrupts


Problem: Software can enable DTS thermal interrupts by programming the thermal
threshold and setting the respective thermal interrupt enable bit. When
programming DTS value, the previous DTS threshold may be crossed. This
will generate an unexpected thermal interrupt.

Implication: Software may observe an unexpected thermal interrupt occur after
reprogramming the thermal threshold.

Workaround: In the ACPI/OS implement a workaround by temporarily disabling the DTS
threshold interrupt before updating the DTS threshold value.

Status: For the steppings affected, see the Summary Tables of Changes.[...]

Quelle: www.Intel.de

In dem Dokument heißt es sogar, dass dafür kein Fix geplant sei.

Machen Programme wie CoreTemp oder RealTemp denn etwas in der Richtung?

Wenn du was anderes meinst, dann bitte ich um eine Quelle.
 
Zuletzt bearbeitet:
jupp, das ist genau das problem - dann kann entweder im register müll stehen, weil die werte der 2 sensoren chaotisch gemischt eingetragen wurden, oder die sensoren können sich gegenseitig blockieren, usw.

der realtemp-programmierer hat versucht, eine nachträgliche kalibrierung vorzunehmen, aber irgendwie ist das auch nicht wirklich reliable...

zur tjunction - leider dokumentiert intel das bei den desktop-cpus anscheinend noch weniger als amd (hieß dort tcasemax - und stand wirklich im entsprechenden register) und die tool-programmierer müssen das über umwege (z.b. spec-tabellen) implementieren...
 
Bei Intel gibt es gar keine offizielle Dokumentation zur TJunction/TJ.Max. Zu AMD kann ich nichts sagen, da ich mich seit dem Wechsel zu Intel nicht mehr wirklich mit beschäftigt habe.

Der Wechsel zu 45nm hat wohl zu einigen Problemchen geführt, doch ist es nicht generell so, dass durch die Programme falsch ausgelesen wird. Das Hauptproblem besteht darin, dass es wohl vorkommen kann, dass einige Sensoren spinnen. Die bleiben einfach bei einer Temperatur stecken du fallen nicht weiter ab. Das kommt bei den 45nm CPUs des Öfteren im Bereich der IDLE-Temperaturen vor. Hier werden dann falsche Werte der DT-Sensoren geliefert, die das Programm dann einzeigt. Dies sieht dann meist so aus, dass die Idle-Temps hoch ausfallen. Zum Beispiel 53°C. Steigen nun aber die Last-Temperaturen und gehen über den gemeldeten Wert von 53°C hinaus, reagiert der Sensor wieder korrekt und die gemeldeten DTS-Werte stimmen wieder. Sinkt nun die Temperatur im Idle wieder ab, so bleibt der Sensor wieder bei den 53°C stehen und geht nicht tiefer.

Das Problem, was nun wirklich vorherrscht ist, dass es einige User gibt, die eine so hohe Idle-Temp haben, dass sie selbst unter Last den gemeldeten Wert nicht überschreiten. Als Beispiel User, deren Temps dann nur bis 45°C geht. Der Sensor hängt aber bei den 53°C. Dementsprechend kann dann keine korrekte Temperatur angezeigt werden.

(Die Temperaturangaben sind nur Beispiele).

Das nun also grundsätzlich Müll ausgelesen wird, kann ich nicht so stehen lassen. Das muss man mit seiner CPU einfach testen. Und um zum Thema Delta-Werte zurückzukommen muss ich nochmal schreiben, dass man sich diese anzeigen lassen sollte, sofern man der Meinung ist, dass die Last-Temperaturen nicht stimmen. Womit wir wieder bei der TJunction/TJ.Max sind, die von Intel nicht dokumentiert und daher angenommen oder von den Real-Temp Machern selbst abgeleitet/gemessen wird. Man könnte jetzt Speedfan oder Real-Temp nutzen und die Temperatur durch das Programm korrigieren lassen. Dazu wird dann vom Programm auf die gemeldete Temperatur der Differenzwert (den man selbst angeben muss) hinzuaddiert.
 
teilack.

es ist nicht gesagt, daß nur die idle-werte betroffen sind, wie du es darstellst.

der fehler ist ja, daß die dts, die abwechselnd ihre werte in das register schreiben, nicht zuverlässig darauf warten, daß der andere mit dem übergeben der werte fertig ist.

dabei ist es egal, bei welchen werten die dts sich über ihre interrupts blockieren oder ihre werte gegenseitig teilweise überschreiben.

mir sind zu viele annahmen drin, wie die tools zur zeit messen.


jeder prozessor hat ja noch eine diode, die nach genauen vorgaben ausgewertet werden soll - vom mainboard. (die oben bereits genannte...)
[edit]
das nehm ich teilweise zurück - die 8xxx haben laut dem thermal design guide (31873401.pdf s.39) nur noch dts. :eek:
die cpus davor hatten noch beides (thermal design guide 317804.pdf s.39)


-> die ist zwar relativ träge, aber dafür zuverlässig. und wenn man sein kühlsystem mal abgestimmt hat, ist der keks doch gegessen.
 
Zuletzt bearbeitet:
[...]
es ist nicht gesagt, daß nur die idle-werte betroffen sind, wie du es darstellst.
[...]
So wird es aber beschrieben. Das kann man z.B. bei www.xtremesystems.org so nachlesen.

der fehler ist ja, daß die dts, die abwechselnd ihre werte in das register schreiben, nicht zuverlässig darauf warten, daß der andere mit dem übergeben der werte fertig ist.
Woher weist du das schon wieder? Das geht aus der AW30 nicht hervor, bzw. verstehe ich die AW30 da anders. Denn es geht da doch darum, dass externe Software beim Programmieren der DTS Probleme verursachen kann.
 
Zuletzt bearbeitet:
So wird es aber beschrieben. Das kann man z.B. bei www.xtremesystems.org so nachlesen.

der programmierer versucht den steigungsfehler nachzukalibrieren, nicht mehr und nicht weniger.

auch seine messmethode für die tjunction spukt eher die tcase aus (nur bei mobilen cpus ohne ihs wird so tjunction gemessen - siehe specfinder)... thermtrip (notabschaltung) soll ja laut specs 20-25°k über tcasemax greifen.
aber die pdfs sind wirklich geizig mit handfestem...

Woher weist du das schon wieder? Das geht aus der AW30 nicht hervor, bzw. verstehe ich die AW30 da anders. Denn es geht da doch darum, dass externe Software beim Programmieren der DTS Probleme verursachen kann.


es reicht anscheinend schon die abfrage des registers (kostet ja auch zeit und setzt interrupts) durch bios.


die sache mit der gestrichenen diode muss ich mir trotzdem nochmal genauer ansehen bzw. jemand bestimmten im bekanntenkreis nerven...
 
Zuletzt bearbeitet:
Durchs Bios?

Die DTS können durchs Bios doch gar nicht beeinflusst werden!?
 
Endlich mal was Handfestes zum Thema!
Mein Senf dazu: wirklich schwierig wird das auslesen der digi-sensoren
dadurch, daß pro kern UND pro (l2-)cache jeweils ein sensor verbaut ist
(quelle: hardtecs4u) und immer der höchste wert weitergegeben werden soll.
ausserdem hat intel immer mal wieder mit defekten sensoren zu kämpfen
(lt. TAT-dokumentation sind sie z.b. bei verschiedenen pentium-mobiles "broke")
dazu noch die vielen umgelabelten cpus- ich hab nen l2 4300 mit conroe-kern
und tj-max 100°!- jetzt, ein dreiviertel jahr nach erwerb, sind sich zumindest die meisten
tools da einig.
so long
n
 
Durchs Bios?

Die DTS können durchs Bios doch gar nicht beeinflusst werden!?



frag mich nicht - ich hab mir das nicht ausgedacht. :(

der fehler wird scheins ausgelöst, wenn das register ausgelesen wird - irgendwie kommen sich da die dts mit ihren schreib-interrupts und das setzen des interrupts zum lesen des registers in die quere.



btw: realtemp macht das schon nicht schlecht - da die dts darauf kalibriert werden, im kritischen fall zu reagieren, und nach unten hin (idle/kalt) eben ungenau sein können.

trotzdem behebt das nicht den fehler, wenn die sensorik steckenbleibt bzw unsinn produziert, und es bleibt immer noch die frage nach der korrekten ermittlung der maximaltemperatur, von der der dts-wert abgezogen wird.

so gesehen versteh ich jetzt auch deine argumentation, auf die absoluttemperatur zu pfeifen und nur drauf zu schauen, daß man vom kritischen wert genug weit weg bleibt (also nur das "delta", der wert, den die dts ausgeben, beachtet). :bigok:




ich versuch da trotzdem was konkreteres in erfahrung zu bringen - weil ohne extra-diode fürs mainboard läuft die ganze lüftersteuerungsgeschichte über die dts und peci - was mich auch dazu bringt, daß die mainboardbiosse dafür auch gerüstet sein müssen... viel arbeit...
 
Zuletzt bearbeitet:
Ich will auch mal schauen, ob ich da noch weitere Infos finde. Wenn ich was in Erfahrung bringen kann, poste ich es hier. Wenn du was rausbekommst, dann bitte ich dich, es auch hier zu posten.
 
Bis jetzt hab ich die Argumentation mit den Delta Temps soweit verstanden, aber bedeutet das nicht, dass Intel nur die den korrekten Tjmax Wert bekanntgeben müsste und alle mit fehlerfreien Sensoren ausgelieferten CPUs hätte ordentliche Temps sobald das Ausleseprogramm auf diesen Wert aktualiesiert ist?

Und angenommen alle CoreTemps meiner CPU melden von Idle bis 100% Last variierende Temperaturen, hängen also an keinem Wert fest, dann hab ich durch die z.b. mit RealTemp ausgelesenen Delta Werte immer einen ordentlichen Wert den ich beim OC im Auge behalten sollte, richtig?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh