Hallo liebe Leute,
wenig Zeit gabs für mich die vergangenen Wochen, um hier meinen üblichen Senf abzulassen und entsprechend viel hat sich da angesammelt. Beim Blog mit der Nummer 16 also schon gleich zu Beginn die Warnung: Es wird für den geneigten Nerd zwar aufschlussreich (hoffentlich) aber auch mehr zu lesen viel mehr
Was mir die vergangene Zeit im Forum häufig begegnet ist, war ich nenne es mal "naives Vertrauen in Programme aller Art". Beispielhaft eingehen möchte ich auf vier Kandidaten (und Verhaltensweisen), die mir nicht nur ein besonders großer Dorn im Auge sind, sondern mir vermutlich in der Zukunft auch viel Schreibarbeit ersparen wenn ich schlicht auf diesen Blog verweisen kann
Im Einzelnen handelt es sich hier um die Angelegenheiten:
1.) Temperatursensoren
2.) Spannungsanzeigen
3.) SMART Werte
4.) Stabilitätstests
Abschnitt 1: Über die Sinnlosigkeit, sich über 5°C zu streiten.
Immer wieder kommt es vor, dass Posts zu lesen sind wie "ich habe nur 65°C wo mein Kollege schon 70°C hat!" oder "warum ist Kern 1 denn 4°C heißer als Kern 3?". Um hier ein wenig Klarheit zu verschaffen ein kurzer Abriss über Sinn und Funktion der integrierten Temperatursensoren moderner CPUs (und GPUs):
Zum Schutze der Chips kamen findige Tüftler auf die Idee, dass es von Vorteil wäre, wenn sich Chips wenns ihnen zu heiß wird selbst notabschalten könnten bevor sie schmelzen. Zu diesem Zwecke musste der Chip aber "wissen", wie warm ers grade hat und wie warm ers denn haben darf bevor es wehtut. Man musste also einen Sensor anschaffen der die Temperatur(en) misst und festlegen, ab welcher Temperatur abgeschaltet werden soll letztere wird im Folgenden "Tjunction", kurz "Tj" genannt.
Anfangs waren diese Sensoren noch als kleine Thermoelemente extern angebracht und lagen nur an der CPU an, heutzutage sind sie in den CPU-Kern integriert. Der Schritt der Integration brachte aber ein Problem mit sich: Die Thermometer mussten auf Nanometergröße geschrumpft werden (übrigens messen die Winzlinge dadurch natürlich nur die Temperatur an genau dem Punkt des Kerns wo sie eben sitzen und werden entsprechend an möglichst stark beanspruchten Teilen des Kerns, sogenannten HotSpots, angebracht, der Rest des Kerns ist üblicherweise etwas kühler). Man kann sich vorstellen, dass dadurch die Genauigkeit stark gelitten hat aber das ist nicht wirklich ein Problem, denn es ist möglich, die Sensoren relativ genau auf die Abschalttemperatur zu kalibrieren heißt wenn die CPU bei 100°C abschalten soll dann ist der Sensor bei 100°C auch einigermaßen genau und schaltet im richtigen Moment ab. Technisch wird das so gelöst, dass der eigentlich ausgegebene Wert des Sensors immer nur die Temperaturdifferenz zur Tjunction ist so lange der Wert größer als Null ist läuft alles weiter, beim Erreichen der Null wird abgeschaltet.
Dafür ist der Sensor da und NUR dafür!
Das bedeutet, dass alle Temperaturen, die der Sensor in einiger Entfernung zur Tjunction ausgibt (etwa wenn er "40" ausgibt was bei einer Tj von 100°C dann 60°C bedeuten würde), sehr ungenau werden, da diese Werte in dem Bereich nicht kalibriert sind denn es ist ja prinzipiell egal ob 40°C, 60°C oder 80°C anliegen da hier nicht abgeschaltet werden muss. Die Ungenauigkeiten können sich da durchaus im Bereich von 10°C und mehr abspielen, heißt auf deutsch wenn das Programm einen Wert von 50°C ausgibt kann man nur davon ausgehen, dass die wahre Temperatur irgendwo zwischen 40°C und 60°C liegt wenn man Glück hat. Je größer der Abstand zur Tj ist, desto größer wird im allgemeinen auch die Ungenauigkeit bis der Sensor nur noch völligen Käse abliefert was man beispielsweise bei extremen Kühlmethoden sehen kann (OC Profis in dem Bereich nutzen nicht umsonst eigene externe Thermometer).
Zusätzlich ist es so, dass die Tjunction, die ja bekannt sein muss, um den aktuellen Wert zu berechnen, oftmals eben nicht genau bekannt ist, sondern nur geschätzt wird. Bei aktuellen Intel-CPUs (SB, Ivy) geht etwa CoreTemp oftmals von 105°C aus wenn der echte Wert nun 100°C oder 110°C wäre, so wären alle Angaben um weitere 5°C falsch. Den Umstand erkennt man häufig, wenn man mehrere Programme zum auslesen verwendet die intern oftmals verschiedene Tjunctions zugrunde legen und entsprechend verschiedene Werte ausgeben, die sich nur durch einen Offset unterscheiden.
Ich hoffe nach dem Abschnitt ist klar geworden, wie sinnlos es ist, sich da noch über 5°C Unterschied oder gar noch weniger zu streiten. Die große Ungenauigkeit ist auch einer der Gründe, warum oftmals bei OC Versuchen dazu geraten wird, die 70°C oder 75°C nicht zu überschreiten, obwohl die CPU knapp 100°C vertragen könnte. Neben evtl. wärmeren Zimmern, verstaubten Lüftern und sonstigem Allerlei, das die Temperatur zusätzlich hochtreiben kann, ists auch durchaus möglich, dass die CPU bei einer Anzeige von 75°C bereits 85°C oder eben auch nur 65°C hat.
Und am Ende noch ein Wort zu den etwa von Intel angegebenen Maximaltemperaturen (Tmax): Diese beziehen sich (aus Gründen der auf diese Weise viel einfacheren Dimensionierungsrechnung von Kühlanlagen in Serversystemen) auf die Heatspreaderoberfläche, NICHT auf die Kerntemperatur. Die Kerntemperatur ist ein gutes Stück höher im laufenden Betrieb als die Oberfläche der Chipverpackung, daher der Unterschied zwischen Tmax und Tj.
Abschnitt 2: Die spannende Frage nach der Spannung
Oftmals wird geraten "Bei Sandy-Bridge CPUs nicht mehr als 1,35v dauerhaft an vCore!" oder "Mit Loadline Calibration ist die Spannung stabiler/nicht stabiler" und ähnliches. Im Folgenden ist oft zu sehen, dass sich User dann über ein paar Millivolt in der vCore Ausgabe von CPU-Z streiten. Dazu auch ein paar Worte.
Die Betriebsspannung einer CPU (hier vereinfacht angenommen, es gäbe nur die vCore) ist natürlich einer der wichtigsten Parameter was Leistung und Lebensdauer der CPU angeht. Entsprechend komplex ist deren Einrichtung und Verhalten, sie ändert sich mit Energiesparmodi, LLC - Einstellungen, Lastwechseln, hat vDrops und vDroops, VIDs und allerlei sonstigen Krempel, wo Details dazu den Rahmen dieses ohnehin ausufernden Blogs endgültig sprengen würden daher gehts hier mal nur um Sinn und Unsinn von Ausleseprogrammen.
Vielen, die sich mit der Materie beschäftigt haben, wird sicherlich aufgefallen sein, dass die im BIOS/UEFI vorgegebene Lastspannung für die CPU meist nicht genau "getroffen" wird wenn man den gewünschten Wert mit dem ausgelesenen Wert von CPU-Z vergleicht, was mit oben genannten Dingen zu tun hat und normal ist. Dass aber hierbei der in CPU-Z angegebene Wert ebenso wenig stimmen könnte bedenken die Wenigsten der Schrauber.
Das Problem an der ganzen Geschichte ist: Das Auslesen der Spannung ist erstens aus technischen Gründen erstens nur grob aufgelöst und zweitens sehr langsam (niederfrequent). Aufmerksamen Übertaktern wird vielleicht schon einmal aufgefallen sein, dass CPU-Z beispielsweise (abhängig von der CPU) den Wert "1,232v" und den Wert "1,240v" ausgeben kann, nicht aber Werte dazwischen. Das liegt daran, dass die ausgelesene Messgröße nur relativ grob digitalisiert wird: aus allem, was zwischen 1,244v und 1,236v liegt wird aus rein messtechnischen Gründen in diesem Falle "1,240v" bei CPU-Z. Dies ist aber nur die grobe Auflösung der Messgrößenumformung, der eigentliche Messfehler besteht bereits vorher! Wenn also CPU-Z "1,232v" ausgibt heißt das lediglich, dass der Mittelwert der Spannung (dazu gleich mehr) gerade wahrscheinlich zwischen grob 1,21v und 1,26v liegt.
Um professionellen Übertaktern ein genaueres Mittel der Spannungsüberwachung zu geben gibt es daher an teureren Mainboards Spannungsmesspunkte, die die anliegende Spannung direkt durch ein wesentlich genaueres Multimeter abgreifen lassen wenn dieses dann "1,251v" anzeigt kommt das dem Mittelwert der Spannung schon einmal wesentlich näher als das Wert von CPU-Z.
"Warum schreibt der Kerl nun dauernd was von Mittelwerten?" mögen sich einige fragen. Dazu die Gegenfrage: Glaubt ihr denn ernstfaft, ein so extrem komplexes Bauteil wie eine CPU, die bei vielen GHz Takt betrieben ständigen Lastwechseln ausgesetzt ist hätte einen konstanten elektrischen Widerstand und eine immer gleiche Betriebsspannung? Mitnichten!
Die Spannung ändert sich mit jedem Lastzustand und streng genommen fast bei jedem Takt der CPU ständig (ähnlich wie sich die Spannung einer Batterie ändert wenn man Verbraucher an und abschließt probierts aus ). Zwar sind die Spannungswandler betrebt das auszugleichen (was unter anderem die LoadlineCalibration zu beeinflussen vermag, je mehr LLC desto aggressiver dieser Ausgleich), sind dafür aber viel zu träge. Dass der geneigte User davon nichts weiß liegt daran, dass die Multimeter und erst recht die Spannungsanzeige von CPU-Z noch viel träger ist und so schnelle Veränderungen nicht anzeigen kann. Schließt man aber an die Messpunkte ein Oszilloskop an, das prinzipbedingt auch sehr schnelle Spannungswechsel anzeigen kann, so wird man erkennen, dass die Betriebsspannung alles andere als konstant ist, vor allem dann wenn Last zugeschaltet oder weggenommen wird.
Grade wenn man die LLC aggressiv mitmischen lässt kanns durchaus passieren, dass die CPU bei 1,25v vor sich hin werkelt und wenn abrupt die Last wegfällt (der User schließt Prime95 beispielsweise) eine Spannungsspitze für ein paar Millisekunden auf 1,4v schießt (denn die Spannungswandler können nicht so schnell reagieren und "drücken nach"). Aus diesem Grund ist übrigens das offizielle Statement der Hersteller zur LLC, man solle sich bitte nicht nutzen, das nur am Rande.
Insgesamt ist also auch hier große Vorsicht geboten mit Aussagen wie "CPU-Z zeigt bei mir nur 1,232v an!" das muss nicht heißen, dass die CPU niemals auch mal einen 1,35er oder 1,4er Spannungsschlag aushalten muss wenn die restlichen Einstellungen ungünstig gewählt wurden und Diskussionen, ob die CPU von User 1 den gleichen Takt schon mit 0,02v weniger schafft als die von User 2 sind bis zu einem gewissen Punkt wie man nun erkennen kann auch ziemlich inhaltslos (es sei denn sie sind wirklich bei gleichen Bedingungen auf dem gleichen Board getestet und die Spannung an den Messpunkten genauer gemessen worden ).
Abschnitt 3: "Wieso Backup? Meine Platte ist topfit!"
Dieser Spruch wurde auch schon öfter hier gesehen, zumeist in Bezug auf gute SMART-Werte des betreffenden Datenträgers. Umso größer die Ernüchterung, wenn eine "100% gesunde" Platte doch plötzlich nicht mehr mitmachen will und die Bildersammlung von Mutti verloren ist. Da hat einem ein Programm wie beispielsweise CrystalDiskInfo doch bescheinigt, dass sich die Festplatte oder SSD in einwandfreiem Zustand befindet und den nächsten Tag sind alle Daten weg wie konnte das nur passieren? Eigentlich ganz einfach!
Die im SMART System erhobenen Daten spiegeln keineswegs den "Gesundheitszustand" der Festplatte wieder wie einen die Programme mit ihren grünen Ergebnisanzeigen gern glauben machen wollen. Fakt ist, dass jede Festplatte zu jeder Zeit einen Totalausfall erleiden kann das ist nun mal unvermeidlich so. Das SMART System moderner Datenträger ist lediglich ein Hilfsmittel, um unter Umständen einen Ausfall, der sich durch vorangehende Indizien ankündigt, verausahnen zu können. Durch die Indizien, die dafür verwendet werden, kann man evtl. auf eine höhere Wahrscheinlichkeit eines nahenden Defektes schließen, wenn die Werte ungewöhnlich hoch oder niedrig ausfallen. Es darf aber niemals der Fehler gemacht werden zu glauben, dass nur wenn die Werte alle im grünen Bereich sind das Laufwerk ausfallsicher ist lediglich die Wahrscheinlichkeit dafür kann (aber muss nicht!) niedriger liegen!
Übrigens sind die vom SMART registrierten Werte völlig dem Hersteller überlassen und nicht genormt. Das heißt es ist nirgendwo festgelegt, was geloggt werden muss und wo die Grenzwerte sich befinden müssen wenn ein Hersteller also immer gute SMART Werte erzielen will so loggt er eben nur unkritische Kennwerte und setzt die Grenzwerte irgendwo an, wo das Laufwerk sie niemals erreichen kann und schon hat auch eine Platte, bei der es an ein Wunder grenzt dass sie noch läuft einen SMART Wert von 100%. Einfach, oder?
Lange Rede kurzer Sinn: Die SMART-Funktion ist eine nette Spielerei um hier und da mal nachzusehen, ob das Laufwerk irgendwelche verdächtigen Dinge getrieben hat (wenn ich den Herstellern mal unterstelle, dass sie das Systemm sinnvoll einsetzen und nicht schummeln) aber ein Ersatz für ein ordentliches Backup der Daten darf sie niemals sein, denn laut einer Studie können "nur" etwa 64% der Ausfälle durch das SMART System vorhergesagt werden, die restlichen Platten fallen trotz einwandfreier Werte spontan aus (Quelle: http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/de//archive/disk_failures.pdf).
Abschnitt 4: Tücken der Stabilität
"Wieso nur stürzt Battlefield 3 ständig ab wo doch der Furmark ne Stunde läuft und warum bloß bekomme ich in Spielen Bluescreens wo meine CPU doch ganze zwei Stunden Prime95 übersteht?" So oder so ähnlich lauten häufig die Fragen, die mich im Forum oder per PN erreichen und nicht selten tun sich da "Ansichten" von Stabilität auf, die stellenweise durchaus einen wohl zweifelhaften Comedypreis verdient hätten.
Zunächst einmal etwas Grundsätzliches: Stabilität kann niemals bewiesen werden, Instabilität hingegen schon!
Man geht zwar im Allgemeinen davon aus, dass man Systeme, die beispielsweise 24 Stunden am Stück Prime95 fehlerfrei absolvieren als stabil bezeichnen kann, bewiesen ist das aber noch lange nicht denn um Stabilität zu beweisen müsste man theoretisch jede mögliche Anwendung unendlich lange auf dem System laufen lassen, was natürlich unmöglich ist. Das bedeutet umgekehrt, dass ein System bei einer anderen Anwendung auch schon nach 2 Minuten aussteigen könnte auch wenn Prime95 tagelang durchläuft (was zugegeben unwahrscheinlich, aber möglich ist).
Man sollte auch nicht außer Acht lassen, dass verschiedene Anwendungen äußerst verschieden auf leicht instabile Systeme reagieren. So gibt es Spiele, die einfach weiterlaufen wenn die CPU sich mal verrechnet und auch Anwendungen die das kaum juckt (wohl aber unter Umständen den Anwender, wenn das Ergebnis durch den Rechenfehler unbrauchbar wird und er es womöglich erst zu spät oder gar nicht bemerkt schon mal Konvertierungsfehler/Blockfehler in Videoclips gesehen ?). Andere Anwendungen oder Spiele stürzen bei der kleinsten Instabilität sofort mit ach und Krach zu Boden.
Generell könnte man also zunächst festhalten, dass es auf den Zweck des Rechners ankommt, wie stabil er wirklich sein muss. Den gemeinen Zocker dürfte es wenig interessieren, ob der PC sich hier und da mal vertut so lange das Spiel der Wahl problemlos läuft. Auch machts hier keinen Unterschied ob der PC erst nach 4 Stunden Dauerlast aufgibt wenn der geneigte Zocker nie so lange am Stück spielt. Wenn aber der Herr vor dem Bildschirm etwa ein Videobearbeiter ist, so ist es äußerst ärgerlich, wenn die Konvertieraufgabe sagen wir mal 20 Stunden dauert und der Rechner nach 19 Stunden einen Fehler macht und entweder abstürtzt oder (oft noch schlimmer) das Ergebnis des Vorgangs unbrauchbar macht, was wenns blöd läuft erst auffällt wenns zu spät ist.
Der Zocker braucht in diesem Falle einen PC, der "gerade so stabil" ist, dass das gewünschte Spiel läuft, der Videobearbeiter braucht einen Rechenknecht, der auch unter dauerhafter, höchster Last absolut fehlerfrei durchhält. Aber wie nun herausfinden, was wann wie stabil ist?
Dazu muss zunächst die richtige Wahl von Programmen getroffen werden nämlich diejenigen, die tatsächlich als Stabilitätstest gedacht sind! Beispielsweise der immer fälschlicherweise genutzte Furmark gehört NICHT dazu! Dieses Programm provoziert die maximal mögliche Abwärme der Grafikkarte (sofern sie nicht duch künstliche Tricks der Hersteller ausgebremst wird), ob sie dabei stabil ist oder nicht ist dem Programm piepegal sofern es nicht so schlimm ist dass der Treiber eben die Notbremse zieht. Die Folge davon ist, dass der Furmark noch stundenlang bei Taktraten durchlaufen kann, wo viele Spiele bereits abstürzen und der arme Übertakter sitzt mal wieder ratlos vor dem PC.
Hier der Tipp für Grafikkarten: Es ist sinnvoll, den maximalen Takt mit beispielsweise dem Artefacttester des "GPUTools" auszuloten denn dieser zeigt Artefakte (= Rechenfehler) wenn sie denn auftreten auch an und dokumentiert somit die Instabilität. Wenn hier der höchste stabile Takt gefunden wurde sollten verschiedene Programme und Spiele in möglichst fordernden Einstellungen abgefahren werden um zu prüfen, ob nicht doch noch irgendwas zu viel für die Karte wird. Wenn alles längere Zeit problemlos läuft, dann könnte man von "ausreichend stabil" reden.
Wichtig dabei ist, auch moderne Spiele zu nutzen es bringt nichts, etwa Crysis1 als Stabilitätstest zu verwenden, das keine DX11 Effekte darstellen kann und somit die entsprechenden GPU-Teile wenn man denn eine solche Karte besitzt gar nicht benutzt. Entsprechend könnte eine Karte zwei Stunden lang Crysis1 darstellen und bei Crysis2 an den DX11-Effekten bei gleichem Takt in wenigen Sekunden scheitern.
Genau diese Vorgehensweise nutzen im übrigen die Hersteller der Karten auch (nur mit anderen internen und vermutlich weit mächtigeren Tools eben), und wie hoch die Standardtaktraten der Karten sind zeigt bereits, wie stabil wirklich stabil in dem Falle (natürlich mit einem gewissen Sicherheitspolster) wirklich ist. Ausgenommen sind hier wohlgemerkt Partnerkartendesigns als OC-Version da gibts sogar Modelle wo die Partner sebst das oben beschriebene nicht hinbekommen oder aus Kostengründen einsparen was dann Karten zur Folge hat, die schon ab Werk teilweise instabil sind (gell, Gigabyte und EVGA?).
Bei CPUs gestaltet sich die Sache prinzipiell etwas einfacher, da hier oft schon ein einziges Programm ausreicht um die CPU zum Absturz zu bringen: die berühmte Programmbibliothek LinPack zum lösen linearer Gleichungssysteme. Bekanntere Vertreter, die diese nutzen, sind beispielsweise der IntelBurnTest oder das Programm "OCCT". Im Laufe der Zeit hat sich gezeigt, dass moderne CPUs unter der Last von LinPack basierten Programmen meist schneller kapitulieren als sie es bei großen Fast-Fourier-Transformationen (das ist das "large FFT") von Prime95 tun.
Mit diesen Programmen ist es recht einfach, eine Stabilität für seine Zwecke zu erreichen. Man bestimme die Zeit, in der die CPU am Stück stabil arbeiten soll wer 3 Stunden am Stück spielt nimmt 3 Stunden (wobei hier oft auch bereits eine ausreicht im Realfall), wer 10 Stunden rendert eben 10. Eine CPU, die LinPack über 10 Stunden fehlerfrei absolviert, wird höchstwahrscheinlich auch alle anderen Aufgaben in diesem Zeitraum bewältigen ohne einen Fehler zu machen. Und wenn sich jeder daran hält, seine CPU erst dann als "stabil" zu bezeichnen, wenn sie mindestens sagen wir mal eine Stunde LinPack überstanden hat, dann hören vielleicht auch die Kommentare auf von Usern die behaupten, dass ihr 2500K schon bei 1,1v die 4,5 GHz voll mitmacht und so Alter.
So, erstmal herzlichen Glückwunsch an alle, die es bis hier hin geschafft haben (wenn es denn tatsächlich welche geben sollte betrachtet euch als mit einem Keks beschenkt
)!
Als Fazit der Nummer will ich nur festhalten, dass alle diese Programme und Tools, denen einige hier so blind vertrauen nur dann sinnvoll sein können, wenn sie für die richtige Aufgabe genutzt werden, und wenn man die Ergebnisse richtig einzuschätzen weiß. Tools ersetzen nicht den gesunden Menschenverstand, noch sind sie allwissend oder können gar in die Zukunft sehen!
Bitte behaltet das bei der Nutzung immer im Hinterkopf, dann wird es in Zukunft, auch mit dem kleinen Hintergrundwissen dass ich hier ausgebreitet habe, vielleicht weniger Threads und Posts und PNs geben, in denen User mit völlig falschen Vorstellungen von der Arbeitsweise solcher Programme noch falschere Schlüsse ziehen und den allgemeinen Unmut im Forum daduch womöglich noch verstärken wenn sie das alles rausposaunen.
In dem Sinne fröhliches Tool-Nutzen, und guten Appetit beim Keksessen all denen, die sich den ganzen Blog hier angetan haben!
wenig Zeit gabs für mich die vergangenen Wochen, um hier meinen üblichen Senf abzulassen und entsprechend viel hat sich da angesammelt. Beim Blog mit der Nummer 16 also schon gleich zu Beginn die Warnung: Es wird für den geneigten Nerd zwar aufschlussreich (hoffentlich) aber auch mehr zu lesen viel mehr
Was mir die vergangene Zeit im Forum häufig begegnet ist, war ich nenne es mal "naives Vertrauen in Programme aller Art". Beispielhaft eingehen möchte ich auf vier Kandidaten (und Verhaltensweisen), die mir nicht nur ein besonders großer Dorn im Auge sind, sondern mir vermutlich in der Zukunft auch viel Schreibarbeit ersparen wenn ich schlicht auf diesen Blog verweisen kann
Im Einzelnen handelt es sich hier um die Angelegenheiten:
1.) Temperatursensoren
2.) Spannungsanzeigen
3.) SMART Werte
4.) Stabilitätstests
Abschnitt 1: Über die Sinnlosigkeit, sich über 5°C zu streiten.
Immer wieder kommt es vor, dass Posts zu lesen sind wie "ich habe nur 65°C wo mein Kollege schon 70°C hat!" oder "warum ist Kern 1 denn 4°C heißer als Kern 3?". Um hier ein wenig Klarheit zu verschaffen ein kurzer Abriss über Sinn und Funktion der integrierten Temperatursensoren moderner CPUs (und GPUs):
Zum Schutze der Chips kamen findige Tüftler auf die Idee, dass es von Vorteil wäre, wenn sich Chips wenns ihnen zu heiß wird selbst notabschalten könnten bevor sie schmelzen. Zu diesem Zwecke musste der Chip aber "wissen", wie warm ers grade hat und wie warm ers denn haben darf bevor es wehtut. Man musste also einen Sensor anschaffen der die Temperatur(en) misst und festlegen, ab welcher Temperatur abgeschaltet werden soll letztere wird im Folgenden "Tjunction", kurz "Tj" genannt.
Anfangs waren diese Sensoren noch als kleine Thermoelemente extern angebracht und lagen nur an der CPU an, heutzutage sind sie in den CPU-Kern integriert. Der Schritt der Integration brachte aber ein Problem mit sich: Die Thermometer mussten auf Nanometergröße geschrumpft werden (übrigens messen die Winzlinge dadurch natürlich nur die Temperatur an genau dem Punkt des Kerns wo sie eben sitzen und werden entsprechend an möglichst stark beanspruchten Teilen des Kerns, sogenannten HotSpots, angebracht, der Rest des Kerns ist üblicherweise etwas kühler). Man kann sich vorstellen, dass dadurch die Genauigkeit stark gelitten hat aber das ist nicht wirklich ein Problem, denn es ist möglich, die Sensoren relativ genau auf die Abschalttemperatur zu kalibrieren heißt wenn die CPU bei 100°C abschalten soll dann ist der Sensor bei 100°C auch einigermaßen genau und schaltet im richtigen Moment ab. Technisch wird das so gelöst, dass der eigentlich ausgegebene Wert des Sensors immer nur die Temperaturdifferenz zur Tjunction ist so lange der Wert größer als Null ist läuft alles weiter, beim Erreichen der Null wird abgeschaltet.
Dafür ist der Sensor da und NUR dafür!
Das bedeutet, dass alle Temperaturen, die der Sensor in einiger Entfernung zur Tjunction ausgibt (etwa wenn er "40" ausgibt was bei einer Tj von 100°C dann 60°C bedeuten würde), sehr ungenau werden, da diese Werte in dem Bereich nicht kalibriert sind denn es ist ja prinzipiell egal ob 40°C, 60°C oder 80°C anliegen da hier nicht abgeschaltet werden muss. Die Ungenauigkeiten können sich da durchaus im Bereich von 10°C und mehr abspielen, heißt auf deutsch wenn das Programm einen Wert von 50°C ausgibt kann man nur davon ausgehen, dass die wahre Temperatur irgendwo zwischen 40°C und 60°C liegt wenn man Glück hat. Je größer der Abstand zur Tj ist, desto größer wird im allgemeinen auch die Ungenauigkeit bis der Sensor nur noch völligen Käse abliefert was man beispielsweise bei extremen Kühlmethoden sehen kann (OC Profis in dem Bereich nutzen nicht umsonst eigene externe Thermometer).
Zusätzlich ist es so, dass die Tjunction, die ja bekannt sein muss, um den aktuellen Wert zu berechnen, oftmals eben nicht genau bekannt ist, sondern nur geschätzt wird. Bei aktuellen Intel-CPUs (SB, Ivy) geht etwa CoreTemp oftmals von 105°C aus wenn der echte Wert nun 100°C oder 110°C wäre, so wären alle Angaben um weitere 5°C falsch. Den Umstand erkennt man häufig, wenn man mehrere Programme zum auslesen verwendet die intern oftmals verschiedene Tjunctions zugrunde legen und entsprechend verschiedene Werte ausgeben, die sich nur durch einen Offset unterscheiden.
Ich hoffe nach dem Abschnitt ist klar geworden, wie sinnlos es ist, sich da noch über 5°C Unterschied oder gar noch weniger zu streiten. Die große Ungenauigkeit ist auch einer der Gründe, warum oftmals bei OC Versuchen dazu geraten wird, die 70°C oder 75°C nicht zu überschreiten, obwohl die CPU knapp 100°C vertragen könnte. Neben evtl. wärmeren Zimmern, verstaubten Lüftern und sonstigem Allerlei, das die Temperatur zusätzlich hochtreiben kann, ists auch durchaus möglich, dass die CPU bei einer Anzeige von 75°C bereits 85°C oder eben auch nur 65°C hat.
Und am Ende noch ein Wort zu den etwa von Intel angegebenen Maximaltemperaturen (Tmax): Diese beziehen sich (aus Gründen der auf diese Weise viel einfacheren Dimensionierungsrechnung von Kühlanlagen in Serversystemen) auf die Heatspreaderoberfläche, NICHT auf die Kerntemperatur. Die Kerntemperatur ist ein gutes Stück höher im laufenden Betrieb als die Oberfläche der Chipverpackung, daher der Unterschied zwischen Tmax und Tj.
Abschnitt 2: Die spannende Frage nach der Spannung
Oftmals wird geraten "Bei Sandy-Bridge CPUs nicht mehr als 1,35v dauerhaft an vCore!" oder "Mit Loadline Calibration ist die Spannung stabiler/nicht stabiler" und ähnliches. Im Folgenden ist oft zu sehen, dass sich User dann über ein paar Millivolt in der vCore Ausgabe von CPU-Z streiten. Dazu auch ein paar Worte.
Die Betriebsspannung einer CPU (hier vereinfacht angenommen, es gäbe nur die vCore) ist natürlich einer der wichtigsten Parameter was Leistung und Lebensdauer der CPU angeht. Entsprechend komplex ist deren Einrichtung und Verhalten, sie ändert sich mit Energiesparmodi, LLC - Einstellungen, Lastwechseln, hat vDrops und vDroops, VIDs und allerlei sonstigen Krempel, wo Details dazu den Rahmen dieses ohnehin ausufernden Blogs endgültig sprengen würden daher gehts hier mal nur um Sinn und Unsinn von Ausleseprogrammen.
Vielen, die sich mit der Materie beschäftigt haben, wird sicherlich aufgefallen sein, dass die im BIOS/UEFI vorgegebene Lastspannung für die CPU meist nicht genau "getroffen" wird wenn man den gewünschten Wert mit dem ausgelesenen Wert von CPU-Z vergleicht, was mit oben genannten Dingen zu tun hat und normal ist. Dass aber hierbei der in CPU-Z angegebene Wert ebenso wenig stimmen könnte bedenken die Wenigsten der Schrauber.
Das Problem an der ganzen Geschichte ist: Das Auslesen der Spannung ist erstens aus technischen Gründen erstens nur grob aufgelöst und zweitens sehr langsam (niederfrequent). Aufmerksamen Übertaktern wird vielleicht schon einmal aufgefallen sein, dass CPU-Z beispielsweise (abhängig von der CPU) den Wert "1,232v" und den Wert "1,240v" ausgeben kann, nicht aber Werte dazwischen. Das liegt daran, dass die ausgelesene Messgröße nur relativ grob digitalisiert wird: aus allem, was zwischen 1,244v und 1,236v liegt wird aus rein messtechnischen Gründen in diesem Falle "1,240v" bei CPU-Z. Dies ist aber nur die grobe Auflösung der Messgrößenumformung, der eigentliche Messfehler besteht bereits vorher! Wenn also CPU-Z "1,232v" ausgibt heißt das lediglich, dass der Mittelwert der Spannung (dazu gleich mehr) gerade wahrscheinlich zwischen grob 1,21v und 1,26v liegt.
Um professionellen Übertaktern ein genaueres Mittel der Spannungsüberwachung zu geben gibt es daher an teureren Mainboards Spannungsmesspunkte, die die anliegende Spannung direkt durch ein wesentlich genaueres Multimeter abgreifen lassen wenn dieses dann "1,251v" anzeigt kommt das dem Mittelwert der Spannung schon einmal wesentlich näher als das Wert von CPU-Z.
"Warum schreibt der Kerl nun dauernd was von Mittelwerten?" mögen sich einige fragen. Dazu die Gegenfrage: Glaubt ihr denn ernstfaft, ein so extrem komplexes Bauteil wie eine CPU, die bei vielen GHz Takt betrieben ständigen Lastwechseln ausgesetzt ist hätte einen konstanten elektrischen Widerstand und eine immer gleiche Betriebsspannung? Mitnichten!
Die Spannung ändert sich mit jedem Lastzustand und streng genommen fast bei jedem Takt der CPU ständig (ähnlich wie sich die Spannung einer Batterie ändert wenn man Verbraucher an und abschließt probierts aus ). Zwar sind die Spannungswandler betrebt das auszugleichen (was unter anderem die LoadlineCalibration zu beeinflussen vermag, je mehr LLC desto aggressiver dieser Ausgleich), sind dafür aber viel zu träge. Dass der geneigte User davon nichts weiß liegt daran, dass die Multimeter und erst recht die Spannungsanzeige von CPU-Z noch viel träger ist und so schnelle Veränderungen nicht anzeigen kann. Schließt man aber an die Messpunkte ein Oszilloskop an, das prinzipbedingt auch sehr schnelle Spannungswechsel anzeigen kann, so wird man erkennen, dass die Betriebsspannung alles andere als konstant ist, vor allem dann wenn Last zugeschaltet oder weggenommen wird.
Grade wenn man die LLC aggressiv mitmischen lässt kanns durchaus passieren, dass die CPU bei 1,25v vor sich hin werkelt und wenn abrupt die Last wegfällt (der User schließt Prime95 beispielsweise) eine Spannungsspitze für ein paar Millisekunden auf 1,4v schießt (denn die Spannungswandler können nicht so schnell reagieren und "drücken nach"). Aus diesem Grund ist übrigens das offizielle Statement der Hersteller zur LLC, man solle sich bitte nicht nutzen, das nur am Rande.
Insgesamt ist also auch hier große Vorsicht geboten mit Aussagen wie "CPU-Z zeigt bei mir nur 1,232v an!" das muss nicht heißen, dass die CPU niemals auch mal einen 1,35er oder 1,4er Spannungsschlag aushalten muss wenn die restlichen Einstellungen ungünstig gewählt wurden und Diskussionen, ob die CPU von User 1 den gleichen Takt schon mit 0,02v weniger schafft als die von User 2 sind bis zu einem gewissen Punkt wie man nun erkennen kann auch ziemlich inhaltslos (es sei denn sie sind wirklich bei gleichen Bedingungen auf dem gleichen Board getestet und die Spannung an den Messpunkten genauer gemessen worden ).
Abschnitt 3: "Wieso Backup? Meine Platte ist topfit!"
Dieser Spruch wurde auch schon öfter hier gesehen, zumeist in Bezug auf gute SMART-Werte des betreffenden Datenträgers. Umso größer die Ernüchterung, wenn eine "100% gesunde" Platte doch plötzlich nicht mehr mitmachen will und die Bildersammlung von Mutti verloren ist. Da hat einem ein Programm wie beispielsweise CrystalDiskInfo doch bescheinigt, dass sich die Festplatte oder SSD in einwandfreiem Zustand befindet und den nächsten Tag sind alle Daten weg wie konnte das nur passieren? Eigentlich ganz einfach!
Die im SMART System erhobenen Daten spiegeln keineswegs den "Gesundheitszustand" der Festplatte wieder wie einen die Programme mit ihren grünen Ergebnisanzeigen gern glauben machen wollen. Fakt ist, dass jede Festplatte zu jeder Zeit einen Totalausfall erleiden kann das ist nun mal unvermeidlich so. Das SMART System moderner Datenträger ist lediglich ein Hilfsmittel, um unter Umständen einen Ausfall, der sich durch vorangehende Indizien ankündigt, verausahnen zu können. Durch die Indizien, die dafür verwendet werden, kann man evtl. auf eine höhere Wahrscheinlichkeit eines nahenden Defektes schließen, wenn die Werte ungewöhnlich hoch oder niedrig ausfallen. Es darf aber niemals der Fehler gemacht werden zu glauben, dass nur wenn die Werte alle im grünen Bereich sind das Laufwerk ausfallsicher ist lediglich die Wahrscheinlichkeit dafür kann (aber muss nicht!) niedriger liegen!
Übrigens sind die vom SMART registrierten Werte völlig dem Hersteller überlassen und nicht genormt. Das heißt es ist nirgendwo festgelegt, was geloggt werden muss und wo die Grenzwerte sich befinden müssen wenn ein Hersteller also immer gute SMART Werte erzielen will so loggt er eben nur unkritische Kennwerte und setzt die Grenzwerte irgendwo an, wo das Laufwerk sie niemals erreichen kann und schon hat auch eine Platte, bei der es an ein Wunder grenzt dass sie noch läuft einen SMART Wert von 100%. Einfach, oder?
Lange Rede kurzer Sinn: Die SMART-Funktion ist eine nette Spielerei um hier und da mal nachzusehen, ob das Laufwerk irgendwelche verdächtigen Dinge getrieben hat (wenn ich den Herstellern mal unterstelle, dass sie das Systemm sinnvoll einsetzen und nicht schummeln) aber ein Ersatz für ein ordentliches Backup der Daten darf sie niemals sein, denn laut einer Studie können "nur" etwa 64% der Ausfälle durch das SMART System vorhergesagt werden, die restlichen Platten fallen trotz einwandfreier Werte spontan aus (Quelle: http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/de//archive/disk_failures.pdf).
Abschnitt 4: Tücken der Stabilität
"Wieso nur stürzt Battlefield 3 ständig ab wo doch der Furmark ne Stunde läuft und warum bloß bekomme ich in Spielen Bluescreens wo meine CPU doch ganze zwei Stunden Prime95 übersteht?" So oder so ähnlich lauten häufig die Fragen, die mich im Forum oder per PN erreichen und nicht selten tun sich da "Ansichten" von Stabilität auf, die stellenweise durchaus einen wohl zweifelhaften Comedypreis verdient hätten.
Zunächst einmal etwas Grundsätzliches: Stabilität kann niemals bewiesen werden, Instabilität hingegen schon!
Man geht zwar im Allgemeinen davon aus, dass man Systeme, die beispielsweise 24 Stunden am Stück Prime95 fehlerfrei absolvieren als stabil bezeichnen kann, bewiesen ist das aber noch lange nicht denn um Stabilität zu beweisen müsste man theoretisch jede mögliche Anwendung unendlich lange auf dem System laufen lassen, was natürlich unmöglich ist. Das bedeutet umgekehrt, dass ein System bei einer anderen Anwendung auch schon nach 2 Minuten aussteigen könnte auch wenn Prime95 tagelang durchläuft (was zugegeben unwahrscheinlich, aber möglich ist).
Man sollte auch nicht außer Acht lassen, dass verschiedene Anwendungen äußerst verschieden auf leicht instabile Systeme reagieren. So gibt es Spiele, die einfach weiterlaufen wenn die CPU sich mal verrechnet und auch Anwendungen die das kaum juckt (wohl aber unter Umständen den Anwender, wenn das Ergebnis durch den Rechenfehler unbrauchbar wird und er es womöglich erst zu spät oder gar nicht bemerkt schon mal Konvertierungsfehler/Blockfehler in Videoclips gesehen ?). Andere Anwendungen oder Spiele stürzen bei der kleinsten Instabilität sofort mit ach und Krach zu Boden.
Generell könnte man also zunächst festhalten, dass es auf den Zweck des Rechners ankommt, wie stabil er wirklich sein muss. Den gemeinen Zocker dürfte es wenig interessieren, ob der PC sich hier und da mal vertut so lange das Spiel der Wahl problemlos läuft. Auch machts hier keinen Unterschied ob der PC erst nach 4 Stunden Dauerlast aufgibt wenn der geneigte Zocker nie so lange am Stück spielt. Wenn aber der Herr vor dem Bildschirm etwa ein Videobearbeiter ist, so ist es äußerst ärgerlich, wenn die Konvertieraufgabe sagen wir mal 20 Stunden dauert und der Rechner nach 19 Stunden einen Fehler macht und entweder abstürtzt oder (oft noch schlimmer) das Ergebnis des Vorgangs unbrauchbar macht, was wenns blöd läuft erst auffällt wenns zu spät ist.
Der Zocker braucht in diesem Falle einen PC, der "gerade so stabil" ist, dass das gewünschte Spiel läuft, der Videobearbeiter braucht einen Rechenknecht, der auch unter dauerhafter, höchster Last absolut fehlerfrei durchhält. Aber wie nun herausfinden, was wann wie stabil ist?
Dazu muss zunächst die richtige Wahl von Programmen getroffen werden nämlich diejenigen, die tatsächlich als Stabilitätstest gedacht sind! Beispielsweise der immer fälschlicherweise genutzte Furmark gehört NICHT dazu! Dieses Programm provoziert die maximal mögliche Abwärme der Grafikkarte (sofern sie nicht duch künstliche Tricks der Hersteller ausgebremst wird), ob sie dabei stabil ist oder nicht ist dem Programm piepegal sofern es nicht so schlimm ist dass der Treiber eben die Notbremse zieht. Die Folge davon ist, dass der Furmark noch stundenlang bei Taktraten durchlaufen kann, wo viele Spiele bereits abstürzen und der arme Übertakter sitzt mal wieder ratlos vor dem PC.
Hier der Tipp für Grafikkarten: Es ist sinnvoll, den maximalen Takt mit beispielsweise dem Artefacttester des "GPUTools" auszuloten denn dieser zeigt Artefakte (= Rechenfehler) wenn sie denn auftreten auch an und dokumentiert somit die Instabilität. Wenn hier der höchste stabile Takt gefunden wurde sollten verschiedene Programme und Spiele in möglichst fordernden Einstellungen abgefahren werden um zu prüfen, ob nicht doch noch irgendwas zu viel für die Karte wird. Wenn alles längere Zeit problemlos läuft, dann könnte man von "ausreichend stabil" reden.
Wichtig dabei ist, auch moderne Spiele zu nutzen es bringt nichts, etwa Crysis1 als Stabilitätstest zu verwenden, das keine DX11 Effekte darstellen kann und somit die entsprechenden GPU-Teile wenn man denn eine solche Karte besitzt gar nicht benutzt. Entsprechend könnte eine Karte zwei Stunden lang Crysis1 darstellen und bei Crysis2 an den DX11-Effekten bei gleichem Takt in wenigen Sekunden scheitern.
Genau diese Vorgehensweise nutzen im übrigen die Hersteller der Karten auch (nur mit anderen internen und vermutlich weit mächtigeren Tools eben), und wie hoch die Standardtaktraten der Karten sind zeigt bereits, wie stabil wirklich stabil in dem Falle (natürlich mit einem gewissen Sicherheitspolster) wirklich ist. Ausgenommen sind hier wohlgemerkt Partnerkartendesigns als OC-Version da gibts sogar Modelle wo die Partner sebst das oben beschriebene nicht hinbekommen oder aus Kostengründen einsparen was dann Karten zur Folge hat, die schon ab Werk teilweise instabil sind (gell, Gigabyte und EVGA?).
Bei CPUs gestaltet sich die Sache prinzipiell etwas einfacher, da hier oft schon ein einziges Programm ausreicht um die CPU zum Absturz zu bringen: die berühmte Programmbibliothek LinPack zum lösen linearer Gleichungssysteme. Bekanntere Vertreter, die diese nutzen, sind beispielsweise der IntelBurnTest oder das Programm "OCCT". Im Laufe der Zeit hat sich gezeigt, dass moderne CPUs unter der Last von LinPack basierten Programmen meist schneller kapitulieren als sie es bei großen Fast-Fourier-Transformationen (das ist das "large FFT") von Prime95 tun.
Mit diesen Programmen ist es recht einfach, eine Stabilität für seine Zwecke zu erreichen. Man bestimme die Zeit, in der die CPU am Stück stabil arbeiten soll wer 3 Stunden am Stück spielt nimmt 3 Stunden (wobei hier oft auch bereits eine ausreicht im Realfall), wer 10 Stunden rendert eben 10. Eine CPU, die LinPack über 10 Stunden fehlerfrei absolviert, wird höchstwahrscheinlich auch alle anderen Aufgaben in diesem Zeitraum bewältigen ohne einen Fehler zu machen. Und wenn sich jeder daran hält, seine CPU erst dann als "stabil" zu bezeichnen, wenn sie mindestens sagen wir mal eine Stunde LinPack überstanden hat, dann hören vielleicht auch die Kommentare auf von Usern die behaupten, dass ihr 2500K schon bei 1,1v die 4,5 GHz voll mitmacht und so Alter.
So, erstmal herzlichen Glückwunsch an alle, die es bis hier hin geschafft haben (wenn es denn tatsächlich welche geben sollte betrachtet euch als mit einem Keks beschenkt
)!Als Fazit der Nummer will ich nur festhalten, dass alle diese Programme und Tools, denen einige hier so blind vertrauen nur dann sinnvoll sein können, wenn sie für die richtige Aufgabe genutzt werden, und wenn man die Ergebnisse richtig einzuschätzen weiß. Tools ersetzen nicht den gesunden Menschenverstand, noch sind sie allwissend oder können gar in die Zukunft sehen!
Bitte behaltet das bei der Nutzung immer im Hinterkopf, dann wird es in Zukunft, auch mit dem kleinen Hintergrundwissen dass ich hier ausgebreitet habe, vielleicht weniger Threads und Posts und PNs geben, in denen User mit völlig falschen Vorstellungen von der Arbeitsweise solcher Programme noch falschere Schlüsse ziehen und den allgemeinen Unmut im Forum daduch womöglich noch verstärken wenn sie das alles rausposaunen.
In dem Sinne fröhliches Tool-Nutzen, und guten Appetit beim Keksessen all denen, die sich den ganzen Blog hier angetan haben!
) noch nicht.
Würdest du also generell von LLC abraten, oder das ganze nur bei moderatem Einsatz empfehlen? Sagen wir, etwa 4,5 GHz mit 25% LLC oder sowas? Im Prinzip müsste ja der Sinn dadurch gegeben sein, den Offset-Wert etwas tiefer ansetzen zu können - zumindest rein theoretisch finde ich dass es eine sinnvolle Funktion ist, auch wenn ich es bisher nicht gebraucht habe.
.gif "sm_B-) :-)")
