[HowTo] Haswell & Devil's Canyon - Guide und Full Custom Liste
Hallo Luxxer,
ich möchte hier beschreiben, wie man effizient seinen Haswell Chip mit dem Programm Prime95 stabil bekommt.
Es gibt viele Stresstools um sein System auf Stabilität zu testen. Prime95 hat den großen Vorteil, dass man gezielt alle wichtigen Spannungen loten kann, deshalb führt an Prime95 nach wie vor kein Weg vorbei. Dieser Vorteil ist mir in dieser Art und Weise von keinem anderen Programm bekannt. Das erzeugte Szenario unter Prime Volllast erreicht man unter normalen Bedingung niemals.
Ein gewisses Basiswissen ist von Vorteil, aber ich versuche hier zu schildern, dass auch Einsteiger damit was anfangen können.
Ein alltagstaugliches Overclocking ist immer ein Kompromiss aus Leistung und Effizienz.
Silizium wird mit steigenden Temperaturen leitfähiger. Je leitfähiger ein Chip wird, umso mehr Strom kommt zum fließen. Steigt der Strom, steigen die Temperaturen.
Die Kühlung ist ein entscheidender Faktor. Extremes Overclocking mit extremen Kühlmethoden lässt viel höhere Spannungen zu, als unter alltagstauglichen Bedienungen.
Ich schildere hier mal meine Herangehensweise und ihr seit herzlich eingeladen eure Beobachtungen und Erfahrungen zu schildern.
In ralle's hervorragendem OC-Guide stehen viele Details zum Thema. Es handelt sich hier zwar noch um die Vorgängerchips, aber grundsätzlich hat vieles nach wie vor Gültigkeit.
Bei den neuen Chips mit dem Code-Namen Haswell hat man es gleich mit mehreren Neuerungen zu tun.
Desktop 4th Gen Intel® Core? Processor Family: Datasheet, Vol. 1
Bei Haswell hat man zwei von außen einstellbare Spannungen, die Vccin/Eingangsspannung, an die alles angebunden ist und die Vddq.
Alle anderen Spannungen werden über den in den Chip implementierte Fully Integrated Voltage Regulator "FIVR" geregelt, der eine besondere Sensibilität bei Veränderungen an der Eingangsspannung und Ringbusspannung zur Folge hat. Mit der Ringbusspannung/Vring geht der Uncore-Takt einher. An den Ringbus ist wiederum der Arbeitsspeicher angebunden.
FIVR Cutaway View
Jeder Chip ist ein Unikat und bei Haswell ist wirklich alles dabei, von Zicke bis sehr geschmeidiger Chip.
Wenn man aber methodisch und systematisch an die Sache herangeht, bekommt man jeden Chip in den Griff.
Einige wenige Chips sind leider aufgetaucht, die ab Werk nicht default stabil laufen wollen, die dann ein RMA-Fall sind.
Ob der Chip nun einen schlechteren IMC hat oder mehr Cache-Voltage nötig ist, oder halt nur 4.4GHz unter 1.3Vcore machbar sind, man bekommt die Dinger übertaktet stabil.
Leider kann das eventuell sogar noch schlechter aussehen und man muss sich mit weniger Takt zufrieden geben, oder sich einen besseren Chip besorgen.
1.0 VID (Voltage Identification) bei Standard-Takt ist bei Haswell leider nicht mehr so aussagekräftig, wie das früher mal war.
Man sollte die Standard-VID trotzdem ermitteln. Die VID wird mit CoreTemp ausgelesen.
Chips die eine VID von unter 1V haben, haben höchstwahrscheinlich ein sehr gutes OC-Potenzial.
Die VID ermittelt man wie folgt: Bei vielen Boards reicht es aus den Standard-Takt all-cores im Bios zu laden und den Turbo auszuschalten, um die VID im Bios angezeigt zu bekommen.
Die sicherste Methode ist Standard-Takt all-cores im Bios zu laden, Turbo off, Eist off und mit "Prime95 Version 26.6 ohne AVX-Aufschlag" schauen was im Load anliegt.
Die Stock VID muss bei Devils Canyon richtig getestet werden.
Auf dem Z87 OCF reichte es aus, mit den ersten Haswell, Standard Multi und Turbo off einzustellen, um die VID im Bios zu sehen.
Mit den Devils Canyon hingegen muss der Vcore-Modus @ adaptiv gestellt werden, um die VID angezeigt zu bekommen.
@ auto wird sonst immer eine VID von über 1.2V angezeigt. Das könnte bei den Z97 Boards ebenfalls der Fall sein.
www.igorslab.de
1.1 Load Line Calibration
Die Load Line Calibration wirkt bei Haswell auf die Eingangsspannung. Zuvor bei Ivy-Bridge wirkte die LLC auf die Vcore.
In einem alltagstauglichen Setting betreibt man sein System vorzugsweise mit der LLC off.
Der entstehende Spannungsabfall unter Last ist ein gewünschter Effekt. Beim Overclocking ist die Intel Loadline allerdings nur innerhalb gewisser Parameter sinnvoll.
Bei sehr starkem Overclocking wird der Spannungsabfall für einen stabilen Betrieb zu hoch, weshalb man ab bestimmten Taktraten über eine Korrektur nachdenken sollte.
Warum gibt es die Load Line Calibration und was bewirkt sie?
Die Differenz des Spannungsabfall zwischen Idle und Load erreicht bei starkem Overclocking zu hohe Werte, deshalb gibt es die Load Line Calibration um hier entgegenzuwirken.
Man kann den Vdroop/Spannungsabfall durch die LLC immer kleiner werden lassen, komplett abschalten und sogar umkehren, weil extremes OC oft erst mit 100% oder gar einer umgedrehten LLC funktioniert.
Das Phänomen mit der LLC wird bereits seit Sockel 775 Zeiten hart diskutiert und es gibt genug Erklärungen darüber. Die Empfehlung von Intel für den sicheren Dauerbetrieb ist LLC off.
Der Spannungsabfall soll Spannungsspitzen beim Ausschwingen dämpfen. Der Spannungsabfall steigt mit dem Takt und der Last.
Diese kurzen fiesen Peaks/Spannungsspitzen in Lastweschseln kann man mit keinem Multimeter messen bzw. in Monitoring-Tools sehen, sie sind nur mit einem Oszilloskop erkennbar.
Da es keine 100% effizienten Netzteile und Spannungswandler gibt, entsteht bedingt durch die Güte der Spannungsversorgung bereits ein gewisser Vdrop, unabhängig von der Load Line.
Spannungswandler schalten zwar sehr schnell innerhalb von Millisekunden, doch genau das ist die Problematik.
Gerade aus der Last in den Leerlauf entstehen diese fiesen kurzen Peaks/Spannungsspitzen, weil die Schaltgeschwindigkeit eine gewisse Trägheit aufweist.
Es ist ein Trugschluss anzunehmen man könnte mit einer konstanter anliegenden Spannung, die Spannungsspitzen in Lastwechsel verhindern.
Natürlich spielen bei moderner Elektronik/Halbleitertechnik noch andere Faktoren hinein außer Spannung, Leitfähigkeit und der dadurch resultierende Strom.
Ab einem gewissen Punkt muss man einfach mit der LLC gegen den Vdroop arbeiten, um auch bei starkem OC einen stabilen Betrieb zu gewährleisten.
Bei noch moderneren Chips mit mehr Kernen und deutlich höherem Energieaufwand, muss man sich von LLC off Einstellung mit maximalem Spannungsabfall viel früher verabschieden.
Zum besseren Verständnis sollte man sich hierzu den Punkt 7. in Ralle's Guide durchlesen, wo er den Vdrop/Vdroop und das Verhältnis Wärme/Strom gut erklärt.
Grundlagen und Spannungen Voltage Regulation und Loadline/LLC
Erklärung zur LLC und zum Vdrop/Vdroop:
Je nach Board/CPU und angestrebten Takt muss man eventuell in die Load Line gehen, um hohe Takt-Raten ans laufen zu bringen.
Günstige Low-Budget Boards haben bei der LLC oft nur on oder off. Je nach Board und Güte der Spannungsversorgung gibt es auch hier Unterschiede.
Die meisten OC-Boards legen mit Bios-Default Einstellungen 100% LLC an, was wohl zum Ausdruck bringen soll, dass es sich um ein Overclocker Board handelt, nicht weil das für den Dauerbetrieb zu bevorzugen ist.
Bei Low-Budget Boards, wo man nur zwischen on oder off wählen kann, bedeutet LLC on oft = max. Vdroop nach Intel Vorgaben.
Leider kann man hier nicht aus rein logischem Verständnis genau definieren, ob LLC on oder off wirklich on oder off ist.
Deshalb sollt man sich am Spannungsabfall unter Last orientieren, um sicher gehen zu können.
Bei OC Boards, wo man eine LLC Level Steuerung hat, reden wir Overclocker von LLC off, wenn man nicht mit der LLC gegen den Vdroop arbeitet, so wie es für den Dauerbetrieb von Intel vorgesehen ist.
Mit LLC Einstellung @ auto liegt bei den meisten Boards 0.02V mehr an als mit 100% LLC anliegen würde.
Auf den Asrock-Boards ist der LLC Level5 = off und läuft ohne Probleme, sehr weit.
Auf den Asus-Boards ist der LLC Level1 = off. Bei vielen Asus-Boards empfiehlt es sich relativ früh leicht in die LLC zu gehen, um Stabilität zu erreichen.
Auf den Gigabyte-Boards macht sich die LLC Stufe High (~50%) sehr gut. Bei kleineren LLC Stufen oder off, kommt es nach ~ 1h testen zu Problemen.
Auf den MSI sind die verschiedenen LLC Stufen in % von 5-100%. Auf einigen MSI-Boards ist 12,5% die kleinst mögliche LLC Stufe.
Die Load Line Calibration regelt man auf den MSI-Boards unter OC-DigitALL PowerCPU Vdrop Offset Control.
Die LLC Stufe off ist für ein 24/7 Setting zwar zu bevorzugen, aber letztlich muss man das machen was je nach Board/CPU und angestrebten Takt nötig bzw. am besten ist.
1.2 Eingangsspannung VRin/Input-Voltage:
Es gibt eine Regel die besagt, dass eine kleinere Differenz als 400mV zwischen der Eingangsspannung und der Vcore zu Instabilität führt und nicht gut für die CPU ist.
Die Eingangsspannung soll unter Luft bis zu 2.4V unbedenklich sein.
Da solche Angaben meistens aus der Bencher-Szene stammen, sollte man hier zur Sicherheit besser unter 2V bleiben.
Da die Load Line auf die Eingangspannung wirkt und man unter Last @ LLC off einen starken Spannungsabfall hat, dürften knapp unter 2V wirklich unbedenklich sein.
Bei den meisten Chips, die ich hatte, ist z.B. bei 4.5GHz eine Eingangsspannung/Vrin 1.88-1.90V LLC off ausreichend.
Die neuen Devil's Canyon scheinen auf manchen Boards mit reichlich weniger Eingangsspannung auszukommen und auch mit den anderen Spannungen etwas genügsamer zu sein.
Allem Anschein nach hat sich hierzu mit den neuen Bios-Versionen und deren neue Management Engine etwas geändert, was evtl. auch bei den ersten Haswell eine kleinere VRin möglich macht.
Man sollte sich trotzdem besser an die Regel halten und die Differenz zwischen VRin und Vcore nicht kleiner als 400mV werden lassen.
Bei höherem Takt steigt auch die Eingangsspannung und es kann sein, dass man ab einem gewissen Punkt und Board nicht mehr mit LLC off klarkommt.
Für ein 24/7 Setting ist die Load Line Calibration = off zu bevorzugen, es sein denn man hat einen Chip oder Board wo sich LLC off schwierig gestaltet.
Mit den guten Chips konnte ich auf dem Z87M OCF bis 4800MHz im LLC Level5 = off bleiben.
Mit dem sehr guten 4670K sogar bei 4900MHz noch LLC = off bei 1.95V, die im Dauerbetrieb sicher weniger belasten als z.B. 1.90V mit 100% Load Line.
Eine zu hohe, sowie eine zu niedrige Eingangsspannung ist schlecht. Die Input muss genau stimmen und der richtige LLC-Level spielt hier auch eine wichtige Rolle.
Falls man einen Chip erwischt hat der generell viel Vcore benötigt, oder in solche Regionen takten möchte, braucht man dementsprechend mehr Input-Voltage.
Mit fixed eingestellter Eingangsspannung komme ich am besten klar.
1.3 VRing/Cache-Voltage
Früher unter dem Begriff Northbridge bekannt, wird der Uncore-Takt in CPU-Z immer noch so genannt.
Man sollte vorerst mit Standard Uncore-Takt arbeiten. Bei den i5 4670K ist der Standard Uncore-Takt 3800MHz und bei den i7 4770K 3900MHz.
Bei den Devils Canyon 4790K geht der Standard Uncore-Takt bei 4000MHz los.
Ein höherer Uncore-Takt kann sich sehr schwierig gestalten. Alles über 4000MHz Uncore bringt nur noch in Synthetischen-Benchmarks Vorteile.
Hier muss jeder selbst entscheiden, ob einem der Mehraufwand und die höhere Cache-Voltage es wert sind.
Die besseren Chips die ich bisher hatte, kommen bei einem Uncore-Takt von 4200MHz mit einer Vring/Cache-Voltage von 1.131-1.139V aus.
Bei höherem CPU-Takt steigt ab einem gewissen Punkt, meistens höher als 4800MHz dann auch die Vring/Cache-Voltage und bei höherem Uncore-Takt steigt die Cache-Voltage wiederum.
Nicht jeder Chip macht spielend einen hohen Uncore-Takt, die meisten werden jedoch mit 4200MHz Uncore keine Probleme haben, das ist aber kein muss.
Zur Uncore gibt es eine Regel die besagt, dass man optimaler weise mit dem Uncore-Takt 300MHz unter dem Core-Takt bleiben sollte.
Hier ist aber zu bedenken, dass ein Uncore-Takt über 4200MHz sehr schwierig sein kann.
Asus-Boards sollen Probleme haben, großere Differenzen zwischen Core-Takt und Uncore-Takt zu realisieren.
Es ist zu hoffen, dass hier mittels neuen UEFI-Versionen Abhilfe geschaffen wird/wurde.
Ich empfehlen jedem User, der die 4.5GHz CPU-Takt anstrebt, es zuerst einmal mit geringem Uncore-Takt zu versuchen.
Es sei denn, man hat auch mit Standard Uncore Probleme, dann sollte man besser versuchen die 300MHz Differenz zu realisieren.
Bei Standard Uncore sollte die Cache-Voltage zwischen 1.10 und 1.14V gut gewählt sein.
Mit den neuen Devils Canyon berichten einige User bei 4000MHz Uncore mit einer Cache-Voltage von 1.05V auszukommen.
Für ein 24/7 Setting ist eine höhere Cache-Voltage als 1.20V nicht zu empfehlen.
Auch die Cache-Voltage macht sich am besten im Override Modus.
Bei einem Minimum an Vcore und höherem Core/Uncore-Takt, muss bei mir die Cache-Voltage auf's mV genau stimmen.
Auf den meisten Systemen macht sich etwas mehr VRing als mindestens nötigt sind, am Anfang sicher nicht schlecht.
1.4 Vcore und der richtige Modus:
Ein wesentlicher Aspekt zur Load-Vcore im Dauerbetrieb ist die VID. Ein Chip mit hoher VID bleibt viel kühler, als Chips mit kleiner VID.
Bei einem Chip mit kleiner VID ist zwar oft das OC-Potenzial höher, um dauerhaft hohe/n Vcore/Takt fahren zu können ist eine exzellente Kühlung nötig.
Haswell CPUen sollen problemlos 1.4V ab können, aber hier sind die Temperaturen meistens, schon lange bevor man überhaupt in die Nähe dieser Voltage käme, der limitierende Faktor.
Im Allgemeinen werden dieses Chips sehr heiß und eine Vcore Richtung 1.3V sorgt schnell dafür, dass man bei 80°C Kerntemperaturen landet.
Die meisten Haswell sind ungeköpft kaum zu bändigen. Ab 65° Kerntemps kann das Ergebnis schon verfälscht werden.
Man kann die Chips modifizieren, die original Intel TIM gegen eine bessere Wärmeleitpaste tauschen.
Zum Thema CPUen-Köpfen/Modifizieren hier der richtige Thread: Intel Ivy Bridge & Haswell geköpft - Erfahrungen ohne HS bzw. mit gewechseltem TIM
Falls die Enthauptung best möglich erledigt wurde, sind bis zu 30°C besser Kerntemps keine Seltenheit und dann geht natürlich was.
Bei den Haswell und Devils Canyon Chips hat man drei Vcore-Modi zur Auswahl - Adaptiv- Override- und Offset- Vcore-Modus.
Auf den Asrock-Boards kann man nur zwischen Adaptiv oder Override wählen. Offset ist immer präsent, nur muss man sich über den Sinn Gedanken machen.
Auf einigen Asus-Mainboads kann man auch einen reinen Offset-Modus wählen.
Im adaptiven Modus ist es nicht möglich die minimal nötige Vcore zu realisieren, was durch den AVX Aufschlag entsteht.
Auf den Asrock-Mainboards kann man im Override-Modus, die Offset auf auto lassen. Bei den Asrock-Boards funktioniert das hervorragend, ohne Aufschläge.
Zur Sicherheit kann man hier den Aufschlag +0.005V einstellen, um sicher zu gehen, dass das Board hier nicht zu viel drauf packt.
Diese 5mV sollte man deshalb nehmen, da auf dieser Plattform nur 5mv Schritte einen Effekt in den Monitorring-Tools wie CPU-Z bewirken.
Auch für die Cache-Voltage ist eine Offset-Einstellung vorhanden und unterliegt den gleichen Regeln.
Mit Offset kann man die Vcore ins positive oder negative beeinflussen, relativ zur VID.
Falls man Probleme mit Abstürzen im Idle/Teillast hat, könnte man schauen, ob man diese durch positives Offset in den Griff bekommt.
Das wäre z.Z. der einzige Sinn mit Offset im Override Modus, den ich auf dem Asrock Z87M OCF erkennen konnte.
Da der adaptive Vcore-Modus auf allen Boards überhaupt nicht geht, ohne bereits mit AVX mindestens 50mV mehr Vcore als nötig zu haben, habe ich mich damit nicht weiter befasst.
Der adaptive Vcore-Modus macht wahrscheinlich nur @ default Sinn. Die automatisierten Aufschläge sollen wohl alle Eventualitäten berücksichtigen.
Genau wie bei vorgewählten OC-Profilen, wo mit den Spannungen gerne übertrieben wird, wird hier unnötig viel angelegt.
Falls man die Chips mit dem neuen Befehlssätzen AVX2/FMA3 testet, braucht man wiederum mehr Vcore.
Override hat absolut nichts mehr mit der fixed Vcore vergangener Plattformen zu tun, deshalb sollte man sich von dem Begriff fixe Vcore völlig verabschieden, Override nehmen und sich über ein besseres Ergebnis freuen. Zumindest bei den Mainboards wo man nur zwischen Adaptive und Override wählen kann und Offset nicht als eigenständiger Vcore Modus zu nutzen ist.
Der Adaptive Vcore Modus ist @ default auf den meisten Mainboards ausgewählt, aber durch den enormen AVX Aufschlag ist das beim testen mit Prime95 nicht die richtige Wahl.
Haswell hat die modernsten Energiesparfunktionen und schaltet sogar ganze Kerne ab.
Die Monitorring Tools wie CPU-Z zeigen im Override zwar oft unter Last wie im Idle die gleiche Vcore an, was aber kein Problem ist.
Das liegt technisch daran, dass hier die VID von Core 0 und nicht die Vcore ausgelesen wird. Die verschiedenen Kerne haben alle eine eigene VID.
Keine Angst, man spart im Idle trotzdem Energie und die Spannung wird auch im Idle gesenkt, nur meistens nicht richtig von CPU-Z angezeigt.
Auf einigen Mainboards wird es richtig ausgelesen, sogar die gesenkte Vcore im Override Vcore Modus auch mit CPU-Z, auf den meisten Boards eben nicht.
Bei ASRock zeigt das Board eigene Monitoring Tool - Formula Drive oder A-Tuning, die gesenkte Vcore im Idle, auch im Override-Modus an.
Leider zeigt A-Tuning es auch nicht bei jedem Board korrekt an und es wurde auch schon berichtet, dass User es mit ihrem Board mit keinem Tool richtig angezeigt bekommen.
Es ist letztlich auch egal, denn diese User bekommen nur die VID angezeigt und sollten sich da endlich auf die Aussagen anderer verlassen.
Mit einem Energieverbrauchsmessgerät kann man es immer nachvollziehen.
Meine Messung mit Bios-Defaults (Adaptiver Modus) oder 4800MHz@ 1.224V im Override ergibt jeweils 57Watt im Idle.
Die meisten Mainboardhersteller setzen das Konzept mit den Vcore-Modi genauso wie Asrock um, dann ist Override am besten.
Der reine Offset-Modus, der auch eine sofortige Absenkung der Vcore im Idle in CPU-Z zulässt, macht gemessen keinen Unterschied zu Override und ist nicht mit jedem Board möglich.
Warum das Konzept mit den Vcore-Modi verschieden umgesetzt wird ist spekulativ.
Asrock interpretiert es halt so, dass man keinen reinen Offset-Modus nutzen kann.
Da bei Asrock Hardwaredesigner wie Nick Shih tätig sind, dessen Hauptaugenmerk auf guter OC-Performance liegt, kann man davon ausgehen, dass die Interpretation und Implementierung in den UEFIs passt.
Die Vcore wird auch im Override gesenkt, nach längerem Idlen sogar extrem, nur nicht immer korrekt von CPU-Z angezeigt.
Grundsätzlich ist es egal welcher Modus genutzt wird, außer adaptiv, da hier durch AVX oder AVX2/FMA3 viel mehr Vcore im Load anliegt als nötig.
Die Energiesparfunktionen müssen an sein, damit man auch ohne Last (im Idle) Energie spart und die greifen im jedem Modus, egal was von Monitoring Tools angezeigt wird.
EIST und C1E sollten sowieso aktiv sein und der C-State C3 für das Absenken auf ca. 0.8V, C6+C7 für das Absenken auf nahe 0V, durch die Kernabschaltung.
Die Tatsache das im Idle ganze Kerne deaktiviert werden, macht den Vcore-Modus Override absolut alltagstauglich.
Mit HWiNFO könnte es auch angezeigt werden.
Hier ein weiteres Beispiel des Users suali mit gesenkter Idle-VID/Vcore im Override und die Anzeige der verschiedenen CPU-Z Versionen.
1.5 Ram Takt/Vdimm:
Der Ram-Takt und die Vdimm sind immer ein Kompromiss aus Leistung und Effizienz.
Das Ram-Setting testet man mit MemTest. Hier gibt es die Dang Wang Version mit MemTest 4.3.0: Dang Wang RunMemtestPro 4.3.0.rar beim Filehorst - filehorst.de
Im Allgemeinen hat man auf dieser Plattform mit einem 2400MHz Ram-Takt das Optimum an Performance erreicht.
Mit Können und der richtigen Ram/Mainboard-Kombi, kann man durchaus auch ein sehr gutes 2600MHz Setting erzielen.
In den Intel white papers wird eine Vdimm mit 1.575V angegeben, was aber eher für die 1333/1600MHz Module gelten dürfte.
1333 oder 1600er Kit's kommen oft mit 1.5Vdimm daher und aus. Diese dürften für Gamer und Overcklocker aber eher uninteressant sein.
Der größte Teil der Ram-Kit's kommen mit 1.65Vdimm im XMP daher und die meisten 2x8GB Kit's werden bei 2400MHz Takt auch nicht mit viel weniger auskommen, sehr gute Kit's evtl. um die 1.6V.
Bei den 2x4GB Kit's sieht das anders aus. Hier gibt es gute Kit's die 2400MHz Takt mit wenig Vdimm von 1.50-1.520 schaffen.
Dazu muss die CAS-Latency allerdings mit CL9 Kit's auf CL10 erhöht werden.
Bei den Intel-Systemen bringt Takt mehr als Timmigs.
Man kann also auch eine kleinere Vdimm als 1.65V bei sehr guter Performance und hohem Ram-Takt realisieren, teilweise sprechen die CPUen darauf sogar positiv an.
Der Ram-Speicher sollte innerhalb der Spezifikationen laufen und nicht zu Fehlern führen.
Ram-OC macht die Sache natürlich nicht einfacher und kann sich auf der Vcore und SA/VTT bemerkbar machen, was aber erst ab 2000MHz Auswirkungen haben sollte.
Eine Ram-Vollbestückung kann etwas mehr Agent/IMC Voltage nötig machen, eventuell auch mehr Vcore.
Ein kleinerer Ramtakt als 1866MHz sorgt auf der Haswell Plattform für einen nicht unwesentlichen Performance-Verlust, welches in Spielen je nach Takt bis zu 10 Frames ausmachen kann und deshalb die Spieler interessieren sollte.
Hierzu ein interessanter Test: Haswell Real World Performance: DDR3-1600 RAM Speed Is Not Enough - hwbot.org
Dass man bei Ram-OC seine Rams im Griff haben sollte, dürfte klar sein.
Die VTT und Agent/IMC-Voltage spielt dann hier auch keine unwichtige Rolle.
Die VTT auch CPU analog/digital I/O Voltage Offset genannt, stellt man am besten asynchron ein.
Viele User berichten zwar mit auto - Einstellungen auf der Agent und VTT sehr weit zu kommen, aber das hängt wohl auch stark vom Ram und Board ab.
Ich muss mit meinen G.Skill TridentX-F3-2400C9Q-16GTXD @ 2400MHz 10-11-11-21-1T auf dem Z87M OCF eine Agent von +0.016 fahren und eine VTT a/d von +0.030 und +0.025.
Mit den Samsung Green @ 2400MHz war die VTT gleich, aber die Agent etwas höher nämlich +0.018.
Die Agent und die VTT wirken beide auf den IMC, deshalb nicht nur die VTT alleine erhöhen, sondern auch die Agent gleich erhöhen.
Das ist bei 2400MHz Ramtakt ein muss. Das war auch schon auf der Vorgängerplattform so.
Bei 2400MHz Ramtakt sollte die Agent zwischen +0.015 bis +0.020 liegen und die VTT zwischen +0.025/+0.020 bis +0.030/+0.025 auf dem ASRock.
Ist die optimale SA und I/O offset einmal gefunden, passen diese bis zu einem gewissen Punkt auch bei einem anderen CPU-Takt.
Die richtige SA und VTT ist wichtig! Auf Auto-Einstellungen legen die Z87 Boards auf der SA +0.230 und auf der VTT +0.200 an, was grenzwertig und unnötig ist.
Auf den Z97 soll die SA/VTT @ auto auf einigen Boards nicht mehr so hoch angesetzt werden, dennoch setzt man den Wert auch hier besser manuell.
1.6 Ausgangswerte der VTT und Agent:
Auf Asrock hat sich folgendes bewährt: VTT analog/digital Offset = analog 5mV höher als digital einstellen - Agent ab 2400MHz Ram zwischen +0.010 und +0.020
Auf den meisten Asus hat sich folgendes bewährt: VTT analog/digital Offset = digital 50mV höher als analog einstellen - Agent ab 2400MHz Ram zwischen +0.050 und +0.088
Einige User berichten auf ihrem Asus ähnliche Werte wie auf den Asrock zu fahren, nämlich 5mV mehr auf der analogen VTT und auch mit einer kleinen Agent aus zukommen.
Auf MSI sollte man es ruhig wie bei den Asrocks handhaben.
Auf Gigabyte Boards sollen oft synchrone Werte auf der VTT gut sein.
Mit den neuen Devils Canyon sollte man auf einem Z97 Board ruhig auch versuchen mit weniger SA und VTT auszukommen.
1.7 Maximale Voltage-Werte bei Haswell laut Gigabyte-Forum (Bencher-Szene):
Vrin = Input = 2.4V
Vring = Cache = 1.35V
Vcore = 1.45V
SA = Agent = +0.23V über Standard
I/O = VTT = +0.20V über Standard
PCH = 1.15 - 1.20V
DRAM = Vdimm = 2.15V
2.0 Vorbereitungen:
Nachdem man sein System mit Bios-Default-Einstellungen überprüft hat und man sicher ist, dass die CPU i.O. ist und auch der Ram läuft wie er soll, sollte man mit einem moderaten Takt anfangen zu testen.
Leider packt nicht jeder Haswell die 4.5GHz, aber das dürfte man schnell feststellen.
Die minimal nötige Vcore um sauber ins Windows zu booten wird für Prime nicht reichen, hier muss man erfahrungsgemäß zwischen 15-70mV drauf geben.
Mit der Input/Cache solltet ihr euch zunächst an sinnvollen Werten anderer für den gewünschten Takt orientieren.
Je nach Board und deren Eigenheiten tut man gut daran sich zu informieren, wie es bezüglich der VTT und Agent bestellt ist und welche Ausgangswerte hier sinnvoll sind.
Die VTT und Agent wirken beide auf den Ram/IMC, deshalb ist man hier vielleicht gut beraten, gleich beide anzuheben.
Bei Einstellungen der SA und VTT @ auto, legen die Boards viel zu viel an und das muss nicht laufen.
2.1 Prime95
Lange Zeit war das Testen mit der Prime95 Version 27.9 AVX stable aktuell und ausreichend.
Seit Haswell wird von AVX2 gesprochen: AVX2 im Detail: Der erweiterte Befehlssatz für Ivy-Bridge-Nachfolger Haswell
Die Prime95 Version 27.9 reichte grundsätzlich für alle möglichen Szenarien und die Listen-Threads wurden mit dieser Version geführt.
Die Zeit bleibt nicht stehen.
Die neuen Prime95 Versionen haben Vorteile.
1.) Die Stress-Routinen wurden auf moderne Chips angepasst.
2.) Die verkürzte Run Time der FFT-Tests stellt eine große Verbesserung dar, was nicht nur mit Blick auf das Sparen von Ressourcen richtig ist.
3.) Die Verkürzung der FFT Run-Time auf 3min bzw. 6min, sorgt für kürzere Phasen der sehr stark belastenden small FFTs im Bezug auf deren enorme Hitzeentwicklung.
4.) Ich konnte auch eine höhere Sensibilität der neueren Versionen feststellen. Bei selektiven Tests erfolgten Aussteiger einzelner Worker schon nach 2min, die bei gleichem Szenario mit der Version 27.9 erst nach 10min erfolgten.
Neuste Prime95 Versionen GIMPS - Free Prime95 software downloads - PrimeNet
Prime95 Version 29.8 build 6
Mit der Version 27.9 dauert ein kompletter Durchlauf/Full Custom AVX ~ 21h bei 82 FFT-Tests x 15min rechnerisch 1230min.
Mit der Version 29.4 dauert ein kompletter Durchlauf/Full Custom AVX ~ 5,5h bei 79 FFT-Tests x 3min rechnerisch 237min.
Mit der Version 29.8 dauert ein kompletter Durchlauf/Full Custom non AVX ~ 11h bei 88 FFT-Tests x 6 Min. rechnerisch 528 min.
Real variiert die Länge der Laufzeit des Full-Custom Runs, weil im Windows noch andere Prozesse Ressourcen an Rechenleistung benötigen.
Die verkürzte Zeit spart nicht nur Nerven sondern auch Energie.
Prime95-Verlauf Version 27.9 (AVX)
448k, 8k, 512k, 12k, 576k, 18k, 672k, 21k, 768k, 25k, 864k, 32k, 960k, 36k, 1120k, 48k, 1200k, 60k, 1344k, 72k, 1536k, 84k, 1728k, 100k, 1920k, 120k, 2240k, 140k, 2400k, 160k, 2688k, 192k, 2880k, 224k, 3200k, 256k, 3456k, 288k, 3840k, 336k, 400k, 480k, 10k, 560k, 16k, 640k, 20k, 720k, 24k, 800k, 28k, 896k, 35k, 1024k, 40k, 1152k, 50k, 1280k, 64k, 1440k, 80k, 1600k, 96k, 1792k, 112k, 2048k, 128k, 2304k, 144k, 2560k, 168k, 2800k, 200k, 3072k, 240k, 3360k, 280k, 3584k, 320k, 4000k, 384k, 4096k, - random
Prime95-Verlauf Version 29.4 build 8 (AVX)
384K, 8K, 448K, 12K, 512K, 16K, 576K, 20K, 672K, 24K, 768K, 28K, 864K, 35K, 960K, 40K, 1152K, 50K, 1344K, 64K, 1536K, 80K, 1680K, 96K, 1792K, 112K, 2048K, 128K, 2400K, 144K, 688K, 168K, 3072K, 200K, 3360K, 240K, 3584K, 288K, 336K, 400K, 10K, 480K, 15K, 560K, 18K, 640K, 21K, 720K, 25K, 800K, 32K, 896K, 36K, 1024K, 48K, 1280K, 60K, 1440K, 72K, 1600K, 84K, 1728K, 100K, 1920K, 120K, 2304K, 140K, 2560K, 160K, 2880K, 192K, 3200K, 224K, 3456K, 256K, 3840K, 320K, 4032K, 4096K, - random
Prime95-Verlauf Version 29.8 build 6 (non-AVX)
192K, 4K, 224K, 240K, 5K, 256K, 288K, 320K, 6K, 336K, 384K, 400K, 8K, 448K, 480K, 10K, 512K, 560K, 576K, 12K, 640K, 672K, 720K, 14K, 768K, 800K, 16K, 896K, 960K, 1024K, 20K, 1120K, 1152K, 1200K, 24K, 1280K, 1344K, 28K, 1440K, 1536K, 1600K, 32K, 1680K, 1728K, 1792K, 40K, 1920K, 2048K, 48K, 2240K, 2304K, 2400K, 56K, 2560K, 2688K, 2800K, 64K, 2880K, 3072K, 72K, 3200K, 3360K, 3456K, 80K, 3584K, 3840K, 4096K, 84K, 4480K, 4608K, 96K, 4800K, 5120K, 5376K, 112K, 5600K, 5760K, 6144K, 128K, 6400K, 6720K, 144K, 6912K, 7168K, 7680K, 160K, 8000K, 8192K, - random
Seit den Versionen 28.x wird der Befehlssatz FMA3 angesprochen. Auf der Haswell-Plattform benötigt man dazu ~ 50mV mehr Vcore über dem AVX stabilen Wert.
Es ist von Intel nicht vorgesehen diese Chips dauerhaft auf allem Kernen mit FMA3 Befehlssatz zu stressen.
Programme wie Intel Extreme Tuning Utility XTU sprechen nur kurzzeitig einzelne Kerne mit FMA3 an.
Deshalb sollte man auf Haswell und Devils Canyon beim Testen mit der Prime95 Version 29.4 den Befehlssatz FMA3 deaktivieren.
Dazu muss man den Befehl CpuSupportsFMA3=0 in der local.txt Datei setzen und diese schreibgeschützt machen.
Man muss die Prime-Instanz einmal gestartet haben, damit die local.txt Datei entsteht.
Der Verlauf der FFT-Tests ändert sich, wenn man Befehlssätze wie FMA3 oder AVX deaktiviert.
Seit den ersten Six-Core Chips für Mainstream Sockel 1151, sowie des Sockel 2066, wird das Testen von Prime95 ohne AVX wieder Mode und reicht auch für meisten Anwendungen und Spiele.
Seit der Prime95 Beta Version 29.5 build 9 braucht man nun keine Befehlssätze mehr in der Local.txt zu deaktivieren, kann dies direkt im Programm wählen.
Mit AVX2 (fused multiply-add) deaktiviert man den Befehlssatz FMA3.
Neuerung: jetzt kann man gleich im Programm AVX512 - AVX2=FMA3 - AVX abwählen.
Mit den neuen Management Engine Interfaces und den neuen Prime-Versionen empfehle ich, sich nicht mehr mit sehr langen selektiven Tests einzelner FFTs abzugeben, sondern zu versuchen schnellst möglichen einen Prime-Custom Run zu absolvieren.
Selektives Testen einzelner FFT-Test ist nach wie vor die richtige Methode, um sich den optimalen Spannungen zu nähern, mehrmals passed a 3min bzw. 6min dürfte reichen.
Bis Kabylake wurden Listen-Runs mit der Version 27.9 mit 1.5h Mindestlaufzeit geführt.
Seit Skylake-X und Coffeelake S/R wird die Version 29.4 build 8 genutzt und die Laufzeit auf 45min verkürzt und auch non AVX-Runs gelistet.
Gerade was das Verschwenden von Ressourcen angeht, ist das eine zeitgemäße Entscheidung.
Windows7 muss das Service Pack 1 integriert sein, sonst wird der Befehlssatz AVX nicht angesprochen.
Prime95 32Bit Versionen machen nur Sinn, wenn man ein Betriebssystem in 32Bit Variante nutzt.
Anderen Falls macht man sich selbst etwas vor, denn Prime95 in 32Bit auf einem 64Bit Betriebssystem braucht weniger Vcore, als wirklich nötig.
Davon abgesehen ist die Speicherverwaltung in 32Bit Betriebssystemen auf 3.5GB limitiert.
Ältere Prime-Versionen wie 26.6 fordern moderne Chips wie Haswell nicht mehr ausreichend, um Aussagen über die Stabilität treffen zu können.
Für selektive Tests wählt man Custom, stellt links wie rechts im Fenster min-FFT und max-FFT den entsprechenden FFT-Test ein, z.B. 800K für Ram, setzt den Hacken "Run FFTs in-place" - Feuer frei...
Voltages mit einzelnen FFT-Tests identifizieren
1344K = Vcore
448K = Vrin/Input
512 u. 576K = Cache/Uncore
672-720K = VTT/ IO-Voltage
768K = Agent/IMC
800K = Vdimm/Timings
864K = hier spielen alle Komponenten hinein
Einen Custom-Run startet man mit den Standard-Einstellungen z.B Version 27.9 von 8-4096K "Run FFTs in-place".
Die Reihenfolge des Ablaufs der FFT-Tests, sowie die Run-Time unterscheiden sich zwischen den Versionen.
Der Custom Run belastet durch die ständigen Wechsel zwischen small und large FFTs etwas härter, als es beim selektiven Testen der Fall ist.
Falls man Prime unbeaufsichtigt laufen lässt und es im Test-X ausgestiegen ist, kann man im results.txt sehen bis wohin Prime gelaufen ist.
Der letzte passed aller Kerne wird angezeigt und logischerweise ist es dann im darauf folgendem Test ausgestiegen, oder ein Kern oder mehrere Kerne haben den passed nicht geschafft.
Es gibt zwei verschiedene Ergebnisse des Custom-Run mit Prime95.
Als erstes der sogenannte Listen-Run, der sich mit möglichst wenig Vcore am besten eignet, um schnellst möglich ein vergleichbares Ergebnis zu erzielen.
Als zweites das sogenannte rockstable Setting, welches am besten durch den Full-Custom-Run "ein kompletter Durchlauf" untermauert wird.
Der sogenannte Custom-Run sollte mindestens 2,5h durchhalten, um von einer Alltagsstabilität ausgehen zu können.
Prime95 ist nur eines von vielen Stabilitätstest-Programmen, aber sehr aussagekräftig.
Der große Vorteil von Prime95 ist, dass man gezielt alle Spannungen abstecken/loten kann.
Alle Prime95 Versionen
3.0 Kurzanleitung:
Am Anfang schätzt man Voltages wie die VRin und VRing.
Die VRing kann zu Anfang ruhig etwas höher als nötig eingestellt werden.
Mit dem Ram-Setting auf sichere Werte gehen und genügend Vdimm einstellen. Zu Anfang besser etwas mehr als zu wenig einstellen.
Wenn man eine stabile Basis hat, kann man sich mit dem Ram-Setting noch genauer befassen.
Mit der SA und VTT an Werten anderer, je nach Ram/Takt und Board, orientieren.
Hierzu wurden ein paar Kombis für 2400MHz Ram-Takt und verschiedene Boards erwähnt.
Wenn man mit einer Vcore X ins Windows kommt, ist diese entweder schon gut geschätzt, oder man muss die Vcore für Prime erhöhen.
In der Regel braucht es mindestens 20mV mehr Vcore, eher mehr für Prime, als die kleinst mögliche bootbare Vcore.
Falls es jetzt zu Aussteigern kommt, kann man an Hand der BSOD's deuten woran es liegt.
Symptome sind weiter unten erklärt.
Man variiert so lange die Vcore/VRin bis 1344K mindestens 30min = 2x passed läuft.
Wenn jetzt 448K 1x passed im Custom läuft, steht die Eingangsspannung vorerst.
Falls es später im Custom Run zu Reboots ohne Blusscreen kommt, muss man die Eingangsspannung erneut erhöhen.
Nun testet man die VRing/Cache/Uncore bis 512K und 576K mindestens 30min = 2x passed laufen.
Optimaler weise checkt man jetzt die SA/VTT genauer.
Ab wann man einen mehrstündigen Custom Run wagen kann, sollte jeder für sich entscheiden.
Ein ausgiebiges selektives Testen, ist bei Problemen auf jeden Fall nötig. Um optimale Ergebnisse und Stabilität zu erreichen ist das kein Luxus.
3.1 Ausführliche Anleitung:
Man testet zuerst mit 1344k, weil hier die anderen Faktoren am wenigsten hineinspielen, deshalb ist es die beste Methode sich der richtigen Vcore zu nähern.
Man muss systematisch vorgehen. Essenziell bei Haswell ist die Eingansspannung/Input.
Zu aller erst muss die 1344K mindestens 30min in Verbindung mit der richtigen Vcore/Input im richtigen LLC Level stehen, bevor man die anderen Voltages weiter eingrenzen kann.
Am Anfang im Näherungsverfahren macht es noch nicht viel Sinn, die Vcore länger als 30min laufen zu lassen.
Die 864K kommt am härtesten und braucht mehr Vcore als 1344K, was aber erst für ein rockstables Setting relevant wird.
Im Näherungsverfahren ist man evtl. besser beraten, mit der Vcore noch am unteren Limit zu bleiben, um zu verhindern, dass man mit der Vcore evtl. andere Spannungen deckelt.
Deshalb sollte man zuerst einen Listen-Run mit möglichst wenig Vcore hin bekommen. Um mit möglichst wenig Zeitaufwand vergleichen zu können, ist der Listen-Run nach wie vor sinnvoll.
Wenn dann 1344K mindestens 30min durchhält, sollte die Eingangsspannung auch schon halbwegs passen, oder sie stimmt sogar schon.
Um die Input dann genauer zu prüfen sofort den Custom-Run starten, falls es durch 448K läuft steht die Input vorerst, oder man muss erneut nach korrigieren, oder den LLC Level anpassen.
Jetzt kümmert man sich um die Cache-Voltage, die auch jeweils 30min durchhalten sollten. BSODs und Symptome sind weiter unten aufgeführt.
Manche Chips reagieren sehr empfindlich auf der Cache-Voltage. Falls es sich sehr schwer gestalten sollte, die richtige Input zu finden, kann eine falsche Cache-Voltage daran schuld sein.
Dazu gehört dann Feingefühl, auch gleich andere Voltages einzuschränken, wenn man von der Testreihenfolge her irgendwo nicht weiter kommt.
Es gibt auch Chips die deutlich mehr Cache-Voltage benötigen, wobei auch eine höhere Differenz als 300-500MHz zwischen CPU- und Uncore-Takt hinderlich sein kann.
Die User die ihren Ram mit Standard 1600MHz laufen lassen und die Agent und VTT auf auto lassen, können sich 720-768-800K evtl. sparen.
Bei den meisten Systemen mit höherem Ram-Takt ist es sicher von Vorteil, die I/O Offset = VTT und System Agent gleich auf sinnvolle Ausgangswerte zu setzen.
Wer Rundungsfehler auf einzelnen Kernen hat, kommt nicht um die Anpassung der SA und I/O Offset = VTT herum.
Die Ausgangswerte für die Agent und VTT können je nach Board und Ram variieren. Ich halte generell nichts davon solche wichtigen Einstellungen auf auto zu lassen, ganz davon abgesehen, dass diese @ auto viel zu hoch sind. Wer sich mit allen wichtigen Spannungen auseinandersetzt, kann höchstwahrscheinlich einiges an Vcore sparen.
Falls es Probleme beim finden der Cache / SA und VTT gibt, tut man gut daran diese Tests selektiv länger zu testen. Bis zu 90min ist dann nicht verkehrt, um sicher zu gehen.
Wenn die Vdimm bei mir nicht reicht, gibt es Neustarts nach über 45min, beim selektiven Testen von 800K.
Bei Haswell kann man bevor man den Custom Run startet, den Vcore-Test 1344K auch etwas länger laufen lassen, bis zu 1.5h, bei manchen Chips steht die Vcore dann zu 99,99%, zumindest für einen 2-4h Run.
Das ist aber leider nicht bei jedem Chip eine Garantie, dass die Vcore schon fast 100% steht. Ich hatte Chips hier, die mit 30min getesteten 1344K einen Listen-Run schaffen, aber andere wie weiter unten in Eigenarten beschrieben nicht. Wer bereits alle wichtigen Spannungen wie die Vcore/Input/Cache und SA/VTT abgesteckt hat und jetzt im Custom-Run die kleinen FFTs 8-12-18K nicht wollen, liegt das wie in Eigenarten beschrieben, nur noch an der Vcore. Bis hierhin sollte euer Setting für einen Listen-Run reichen, welche hier im Intel Haswell & Devil's Canyon (Sockel 1150) OC-Ergebnis-Thread gepostet werden können:
Ich empfehle zwar am Anfang im Näherungsverfahren mit der Vcore noch am unteren Limit zu bleiben, um zu verhindern, dass man mit der Vcore andere Spannungen deckelt, dennoch muss die Vcore ausreichend sein.
Leider gibt es auch Chips bei denen es besser ist, sich nicht zu viel mit den 1344K zu beschäftigen.
Für einen Listen-Run mag ein 1344K Setting noch ausreichend sein, aber für einen mehrstündigen Custom-Run oder ein rockstables Setting braucht es eh mehr Vcore.
Bei sehr schwierigen Chips, bei denen wirklich alle Nebenspannungen genau stimmen müssen, kann es vorkommen, dass man sich sehr schwer tut nach der empfohlenen Vorgehensweise klar zukommen.
Gerade bei solche problematischen Chips empfiehlt es sich, sich schon früh mit den 864K auseinanderzusetzen.
Die 864K fordern sehr stark, hier spielen alle Spannungen mit hinein und AVX wird besonders stark angesprochen.
Listen Run 4800/4200/2400MHz:
3.2 Rockstable:
Das gezielte selektive Testen, ist die beste Methode sich den optimalen Werten zu nähern.
Wer glaubt er könne die Aussteiger gleich im Custom-Run richtig deuten, der irrt sich. Das ist viel schwieriger, das kann funktionieren, hat dann aber sicher viel mit Glück zu tun.
Zeitaufwendig ist es eh und letztlich nimmt es sich kaum etwas, ob nun mehrere Custom-Runs nach einiger Zeit aussteigen, oder man gezielt alle wichtigen Tests selektiv laufen lies.
Nach meiner Erfahrung hält ein für die Liste stabiler Run oft auch länger durch, es sei denn die Vcore ist wirklich noch am unteren Minimum, dann schafft man eventuell gerade die 1.5h.
Der Run kann auch länger durchhalten, bis zu 3h oder länger, aber dann kommen unwiderruflich Aussteiger, ohne erneut mehr Vcore geben zu müssen.
Jede Vcore Erhöhung kann dafür sorgen, dass es länger läuft, aber selbst nach 10h und mehr kann es erneut zu Fehlern kommen.
3.3 Der Full Custom-Run
Diese Ausführungen stammen aus den Anfangszeiten dieser Plattform, wo man noch ausschließlich mit der Version 27.9 testete.
Mit den neueren Bios/ME-Updates ist es auch nicht mehr so sensible, wie es damals zum Haswell Release war, wo Spannungen aufs mV stimmen mussten.
Ich denke, damit haben sich solche langen Prime-Run erledigt. Mit der Version 29.4 hat man bereits nach ~ 4,5-5h alle FFT-Tests durchlaufen, wo man mit 27.9 noch ~21h benötigte.
Man kann leider nicht vorhersehen, wie viel mehr Vcore nötig ist, damit es klappt und das System auch sonst in allem Szenarien stabil bleibt.
Leider kann man nicht einfach z.B. 20mV auf den Listen stabilen Wert geben, um sicher zu sein, dass es für den Full Custom Run reicht.
Hier kann eine erneute Vcore-Erhöhung zwischen 15-40mV über den Listen stabilen Werten nötigt sein.
Einfach nur die Vcore erhöhen muss nicht immer funktionieren. Die Eingangsspannung muss evtl. auch noch nach korrigiert werden.
Deshalb sollte man bevor man sich an den Full Custom Run wagt, 864K einzeln länger testen, bis zu 1.5h ist nötig, um sicher zu gehen.
Dazu sollte man aber vorher zumindest einen Listen-Run als Basis geschafft haben.
Falls die Vcore oder Vrin noch nicht reicht, bekommt man beim selektiven testen von 864K entweder Freezes, Kernausteiger oder reboots, was auch nach 45min und über einer Stunde auftreten kann.
Hier ist dann auch wieder Gefühl angesagt, um zu erkennen, ob es an der Vcore oder der Eingangsspannung liegt.
Die Vrin muss genau stimmen. Die Eingangsspannung kann für einen Full Custom Run höher sein, als für einen Listen-Run nötigt ist.
Eine zu hohe Input kann auch wieder reboots erzeugen, meistens aber eher xxx101er BSODs.
Bevor man einen solchen langen Run-Versuch startet, ist es eventuell von Vorteil unnötige Prozesse abzuschalten, um zu verhindern, dass solche den Run eventuell versauen.
Die Energiespar-Einstellungen sollte man im Windows auch so einstellen, dass das OS nicht in den Ruhemodus fährt und den Run verfälscht.
Ab wann Jemand sein System für ausreichend stabil ansieht, ist letztlich jedem seine Entscheidung.
Die Meinungen gehen halt oft auseinander, bezüglich was nötig ist, um von Rock-Stable sprechen zu können.
Es ist auch o.k. wenn jemand berichtet, dass er 5mV über seinem Listen-Run Setting alles machen kann, ohne Abstürze.
Diesbezüglich hat der gute Ralle_h sehr viele Spiele getestet und auch länger am Stück gespielt.
Damit auch wirklich alle Spiele laufen, war nach seiner Aussage der Full-Custom Run nötig.
Nur ca. 50-60% der Spiele liefen mit den 1344k Settings durch, der Rest brauchte den Full Custom.
Hierbei geht es nicht um Rivalität, sondern um Stabilität!
Genauer beurteilen können das nur User, die intensiv mehrere Stunden einige Titel zocken.
Die Aussteiger treten oft erst nach einigen Stunden spielen am Stück auf.
Listen Run vs. Full Custom Run
3.4 Full Custom Run Liste:
4.0 Bei Haswell sollte man nach dem Schwellenwert der Vcore schauen.
Damit ist gemeint, dass man zwar die Vcore in 1mV Schritten einstellen kann, aber nur 5mV Schritte einen Effekt in CPU-Z bringen.
Man kann z.B. im Bios 1.200 Vcore einstellen, aber in CPU-Z wird 1.198 an gezeigt.
Jetzt kann man schauen, wie weit man die Vcore in 1mV Schritten erhöhen kann, damit immer noch 1.198V angezeigt wird.
Falls das z.b. bei eingestellten 1.202 immer noch der Fall ist, wählt man natürlich den höhst möglichen Wert.
4.1 Eigenarten:
Die CPUen haben alle ihre Eingenarten. Bei einem 4770K L315B379 reicht die minimal nötige Vcore um 30min durch 1344K zu kommen, auch für einen mehrstündigen Custom-Run.
Dieser 4770K stieg mir dann allerdings zuerst im Custom-Run in 8K aus, hier war der Schlüssel die Cache 2mV zu erhöhen, dann liefen auch die 8K im Custom. So was findet man dann heraus, wenn man nach anderen Ursachen sucht und nicht gleich die Vcore anhebt.
Bei einem 4770K L311B492 war die 18K die Hürde und dann nur mit mehr Vcore dazu zu bewegen, durch den Custom-Run zu kommen.
Bei dem i5 4670K L313B427 habe ich beobachtet, dass man zwar die Vcore mit 1344K 1.5h abgesteckt haben kann, aber im Custom-Run kommt man nicht durch die kleinen K-Werte 8-12-18K.
Hier half letztlich nur die Vcore um 10mV zu erhöhen, um dann auch die 18K im Custom-Run zu meistern. Ein späterer Freez in 864K war der Anlass hier noch mal genauer zu schauen, an was es liegt.
Leider war erneut mehr Vcore nötig um die Probleme mit 864K zu beseitigen. Erst dann war ein mehrstündiger Custom-Run mit dem i5 4670K möglich.
Meistens sind späte Aussteiger im Custom-Run nur mit mehr Vcore in den Griff zu bekommen, egal ob die Aussteiger in kleinen oder in großen K-werten auftreten.
Wer also in höheren K-Werten jenseits der 768K Aussteiger im Custom hat, bekommt das höchstwahrscheinlich nur mit mehr Vcore in den Griff.
Wer mit solchen späten Aussteigern im Custom-Run kämpft, sollte wissen, dass ein zu hoher Uncore-Takt kontraproduktiv sein kann und man das nicht mehr mit den selektiven Tests, die eigentlich am stärksten auf die Cache wirken herausfinden kann.
Ich teste wirklich sehr akribisch und alle anderen Versuche waren ohne Erfolg.
Deshalb teste ich nach dem selektiven Testen anschließend noch 864K, bei der alle Komponenten hineinspielen.
4.2 BSODs und Symptome:
Hierzu gibt es leider keine allgemein gültigen Aussagen, man muss etwas Spürsinn und Intuition entwickeln.
Bei Haswell bekommt man zum größten Teil xxx124 BSODs, bis man sich mit der Vcore-Input und Cache an die richtigen Werte genähert hat.
Bei Neustarts ohne BSODs und Fehlermeldung stimmt zu 100% die Eingangsspannung noch nicht bzw. ist diese meisten zu niedrig, es kann aber auch bei zu geringer Vcore zu reboots kommen.
Bei xxx101er BSODs stimmt oft Eingangsspannung/Vrin meistens noch nicht, oder es liegt am Verhältnis Vrin/ LLC-Level.
Freezes liegen meist an einer zu niedrigen Vcore oder Vdimm.
Sehr schnelle Aussteiger mehrer Kerne mit rounding errors sind immer auf die Agent zurückzuführen, es ist aber zu bedenken, dass die VTT dort mit hineinspielt.
Ein später Aussteiger im Custom-Run, auch nur mit rounding error auf einem Kern, liegt meistens an der Vcore.
Einzelne Kernaussteiger mit rounding errors können auch an der Vdimm liegen, welches man aber erst feststellen kann, wenn man bereits eine stabile Basis geschaffen hat.
Bei Rounding-Errors die nach einer gewissen Zeit ziemlich gleichzeitig auftreten, liegen eher an der Vdimm.
Rundungs-Fehler mit Dezimalzahl im Code liegen eher an der SA/VTT Kombi.
Falls sich der Prime95 Prozess schließt, ist die System Agent zu hoch.
WHEA Logger in der Windows Ereignisanzeige liegen an zu wenig Vcore. Eine zu geringe Input ergibt reboots, nur können diese auch sehr spät auftreten, nach einigen Stunden.
Eine zu hohe Input kann auch reboots erzeugen, oft aber auch xxx101er BSODs.
Bei einigen Chips kassiert man ab gewissen Regionen Temperatur-bedingt xxx101er BSODs. Hier hilft nur besser kühlen.
Intel hat uns hier eine wirklich schwierige Chip-Generation serviert.
Man muss echte Detektiv-Arbeit leisten um herauszufinden, was bei seinem System nötigt ist.
* 0x124 = VCore
* 0x101 = Input (~ 90 Prozent) oder VCore (~ 10 Prozent)
* 0x1E = VCore
* 0x3B = VCore
* 0x50 = RAM/Cache
* 0x9C = Cache oder System Agent
* 0X109 = Cache/VDimm
* 0x0A = VTT/Sys Agent
Wichtig ist es zu bedenken, dass Voltages wie die System Agent und VTT=I/O Offset in einer Wechselwirkung zueinander stehen.
Ich konnte auch beobachten, dass die Vcore und die VRing/Cach-Voltage ebenfalls in gewisser weise eine Wechselwirkung zueinander aufweisen, bzw. ein hoher Uncore-Takt erst mit genügend Vcore machbar wird. Mit zu knapper Vcore (1.5h Listen Run), ist bei manchen Chips ein hoher Uncore-Takt auch nicht mit mehr VRing=Cache-Voltage durch längere Run's zu bewegen. 4 oder 4.2GHz Uncore stellten keine Hürde dar, schwierig war es die 4.5GHz Uncore-Takt durch längere Runs zu bekommen.
Dieses Verhalten rechtfertigt längere Custom Runs. Erst das Full-Custom Setting als Basis, hat mich tiefer blicken lassen.
Sehr wichtig!
Eine Eigenart dieser Plattform ist, dass man fast bei jeder Veränderung im Bios, gerade an der Eingangspannung und Cache-Voltage, einen obligatorischen Blue-Screen in Prime95 kassiert. Diese Sensibilität liegt sicher daran, dass die Steuerung der Spannungsversorgung in die Chips gewandert ist.
Hiervon darf man sich nicht gleich verwirren lassen und nicht sofort eine Einstellung ändern, sondern einfach erneut starten und mit gleichen Einstellung noch mal versuchen.
Dieser Blaue kommt dann recht schnell innerhalb der ersten Minuten, trotzdem die Veränderung schon richtig gewesen sein kann und führt deshalb oft zu Verwirrung.
Am besten man schaltet den PC nach jeder Änderung einmal aus. Kostet zwar etwas Zeit, spart aber langfristig echt Nerven, da man sich so die ganzen "random" iVR Bluescreens sparen kann.
Eine altbewährte Regel beim Overclocken ist, nicht gleich mehrere Veränderungen auf einmal vornehmen, sondern immer nur eine und schauen was passiert.
Notizen helfen sehr den Überblick zu behalten.
Auch erfahrene Overclocker nutzen zwar die Profile im Bios, aber es geht nichts über ordentliche Notizen.
Es kann vorkommen, dass die Profile im Bios plötzlich nicht mehr vorhanden sind.
Im Fall der Fälle hat man immer noch seine Notizen.
Es gibt auch die Funktion seine Bios-Einstellungen/Profile und Screens zu speichern.
Die Bios-Einstellungen und Profile können aber nur in die jeweilig passende Bios-Version zurück gespielt werden.
Absolut notwendig!
Beim Overclocking sollte man sich über jede Spannung im klaren sein und wie viel hier unbedenklich ist.
Wer mit den ganzen Begriffen noch nicht so sicher ist, sollte sich generell Notizen machen.
Falls man hier VRin und VRing verwechselt könnte fatale Folgen haben.
Ich möchte nicht, dass jemand seine Hardware beschädigt!
Natürlich lebt eine Community vom miteinander.
Dies ist eine Zusammenfassung meiner Erfahrungen und dem Wissen, welches ich bis zu diesem Zeitpunkt sammeln konnte.
Ich nutze auch das Wissen anderer User, welches hier und in anderen Foren veröffentlicht wurde/wird.
Dank an alle Luxxer, die immer sehr gute Tipps geben.
Disclaimer: Overclocking geschieht auf eigene Gefahr!
Kein Anspruch auf komplette Richtigkeit, keine Haftung seitens des Erstellers dieses Threads oder des HardwareLuxx Forum.
Autor: Wernersen
Ich wünsche viel Spaß und Erfolg beim Testen eurer Haswell-CPU/CPUen.
Hallo Luxxer,
ich möchte hier beschreiben, wie man effizient seinen Haswell Chip mit dem Programm Prime95 stabil bekommt.
Es gibt viele Stresstools um sein System auf Stabilität zu testen. Prime95 hat den großen Vorteil, dass man gezielt alle wichtigen Spannungen loten kann, deshalb führt an Prime95 nach wie vor kein Weg vorbei. Dieser Vorteil ist mir in dieser Art und Weise von keinem anderen Programm bekannt. Das erzeugte Szenario unter Prime Volllast erreicht man unter normalen Bedingung niemals.
Ein gewisses Basiswissen ist von Vorteil, aber ich versuche hier zu schildern, dass auch Einsteiger damit was anfangen können.
Ein alltagstaugliches Overclocking ist immer ein Kompromiss aus Leistung und Effizienz.
Silizium wird mit steigenden Temperaturen leitfähiger. Je leitfähiger ein Chip wird, umso mehr Strom kommt zum fließen. Steigt der Strom, steigen die Temperaturen.
Die Kühlung ist ein entscheidender Faktor. Extremes Overclocking mit extremen Kühlmethoden lässt viel höhere Spannungen zu, als unter alltagstauglichen Bedienungen.
Ich schildere hier mal meine Herangehensweise und ihr seit herzlich eingeladen eure Beobachtungen und Erfahrungen zu schildern.
In ralle's hervorragendem OC-Guide stehen viele Details zum Thema. Es handelt sich hier zwar noch um die Vorgängerchips, aber grundsätzlich hat vieles nach wie vor Gültigkeit.
Bei den neuen Chips mit dem Code-Namen Haswell hat man es gleich mit mehreren Neuerungen zu tun.
Desktop 4th Gen Intel® Core? Processor Family: Datasheet, Vol. 1
Bei Haswell hat man zwei von außen einstellbare Spannungen, die Vccin/Eingangsspannung, an die alles angebunden ist und die Vddq.
Alle anderen Spannungen werden über den in den Chip implementierte Fully Integrated Voltage Regulator "FIVR" geregelt, der eine besondere Sensibilität bei Veränderungen an der Eingangsspannung und Ringbusspannung zur Folge hat. Mit der Ringbusspannung/Vring geht der Uncore-Takt einher. An den Ringbus ist wiederum der Arbeitsspeicher angebunden.
FIVR Cutaway View
Jeder Chip ist ein Unikat und bei Haswell ist wirklich alles dabei, von Zicke bis sehr geschmeidiger Chip.
Wenn man aber methodisch und systematisch an die Sache herangeht, bekommt man jeden Chip in den Griff.
Einige wenige Chips sind leider aufgetaucht, die ab Werk nicht default stabil laufen wollen, die dann ein RMA-Fall sind.
Ob der Chip nun einen schlechteren IMC hat oder mehr Cache-Voltage nötig ist, oder halt nur 4.4GHz unter 1.3Vcore machbar sind, man bekommt die Dinger übertaktet stabil.
Leider kann das eventuell sogar noch schlechter aussehen und man muss sich mit weniger Takt zufrieden geben, oder sich einen besseren Chip besorgen.
1.0 VID (Voltage Identification) bei Standard-Takt ist bei Haswell leider nicht mehr so aussagekräftig, wie das früher mal war.
Man sollte die Standard-VID trotzdem ermitteln. Die VID wird mit CoreTemp ausgelesen.
Chips die eine VID von unter 1V haben, haben höchstwahrscheinlich ein sehr gutes OC-Potenzial.
Die VID ermittelt man wie folgt: Bei vielen Boards reicht es aus den Standard-Takt all-cores im Bios zu laden und den Turbo auszuschalten, um die VID im Bios angezeigt zu bekommen.
Die sicherste Methode ist Standard-Takt all-cores im Bios zu laden, Turbo off, Eist off und mit "Prime95 Version 26.6 ohne AVX-Aufschlag" schauen was im Load anliegt.
Die Stock VID muss bei Devils Canyon richtig getestet werden.
Auf dem Z87 OCF reichte es aus, mit den ersten Haswell, Standard Multi und Turbo off einzustellen, um die VID im Bios zu sehen.
Mit den Devils Canyon hingegen muss der Vcore-Modus @ adaptiv gestellt werden, um die VID angezeigt zu bekommen.
@ auto wird sonst immer eine VID von über 1.2V angezeigt. Das könnte bei den Z97 Boards ebenfalls der Fall sein.
Forums-Perle: Der Mythos VID (Voltage Identification Definition) | igor´sLAB
Alt, aber immer wieder und wieder aufgerufen und damit ein absoluter Klassiker vom 14. Mai 2008, also faktisch etwas über 10 Jahre alt. Und das Lustige daran: im Prinzip gilt das damals Geschriebene…
www.igorslab.de
1.1 Load Line Calibration
Die Load Line Calibration wirkt bei Haswell auf die Eingangsspannung. Zuvor bei Ivy-Bridge wirkte die LLC auf die Vcore.
In einem alltagstauglichen Setting betreibt man sein System vorzugsweise mit der LLC off.
Der entstehende Spannungsabfall unter Last ist ein gewünschter Effekt. Beim Overclocking ist die Intel Loadline allerdings nur innerhalb gewisser Parameter sinnvoll.
Bei sehr starkem Overclocking wird der Spannungsabfall für einen stabilen Betrieb zu hoch, weshalb man ab bestimmten Taktraten über eine Korrektur nachdenken sollte.
Warum gibt es die Load Line Calibration und was bewirkt sie?
Die Differenz des Spannungsabfall zwischen Idle und Load erreicht bei starkem Overclocking zu hohe Werte, deshalb gibt es die Load Line Calibration um hier entgegenzuwirken.
Man kann den Vdroop/Spannungsabfall durch die LLC immer kleiner werden lassen, komplett abschalten und sogar umkehren, weil extremes OC oft erst mit 100% oder gar einer umgedrehten LLC funktioniert.
Das Phänomen mit der LLC wird bereits seit Sockel 775 Zeiten hart diskutiert und es gibt genug Erklärungen darüber. Die Empfehlung von Intel für den sicheren Dauerbetrieb ist LLC off.
Der Spannungsabfall soll Spannungsspitzen beim Ausschwingen dämpfen. Der Spannungsabfall steigt mit dem Takt und der Last.
Diese kurzen fiesen Peaks/Spannungsspitzen in Lastweschseln kann man mit keinem Multimeter messen bzw. in Monitoring-Tools sehen, sie sind nur mit einem Oszilloskop erkennbar.
Da es keine 100% effizienten Netzteile und Spannungswandler gibt, entsteht bedingt durch die Güte der Spannungsversorgung bereits ein gewisser Vdrop, unabhängig von der Load Line.
Spannungswandler schalten zwar sehr schnell innerhalb von Millisekunden, doch genau das ist die Problematik.
Gerade aus der Last in den Leerlauf entstehen diese fiesen kurzen Peaks/Spannungsspitzen, weil die Schaltgeschwindigkeit eine gewisse Trägheit aufweist.
Es ist ein Trugschluss anzunehmen man könnte mit einer konstanter anliegenden Spannung, die Spannungsspitzen in Lastwechsel verhindern.
Natürlich spielen bei moderner Elektronik/Halbleitertechnik noch andere Faktoren hinein außer Spannung, Leitfähigkeit und der dadurch resultierende Strom.
Ab einem gewissen Punkt muss man einfach mit der LLC gegen den Vdroop arbeiten, um auch bei starkem OC einen stabilen Betrieb zu gewährleisten.
Bei noch moderneren Chips mit mehr Kernen und deutlich höherem Energieaufwand, muss man sich von LLC off Einstellung mit maximalem Spannungsabfall viel früher verabschieden.
Zum besseren Verständnis sollte man sich hierzu den Punkt 7. in Ralle's Guide durchlesen, wo er den Vdrop/Vdroop und das Verhältnis Wärme/Strom gut erklärt.
Grundlagen und Spannungen Voltage Regulation und Loadline/LLC
Erklärung zur LLC und zum Vdrop/Vdroop:
Was ich primär zum Ausdruck bringen wollte ist, dass es zwar mit LLC auf den ersten Blick so aussieht als würde man VCore sparen/keine hohe Spannung beim Lastenwechsel mehr anliegen haben, aber im Prinzip ist das ein Trugschluss, da man eben die Spannungsspitzen in CPU-Z gar nicht sehen kann.
Hier ein Beispiel (ohne Offset, da man beim Offset den Vdrop/VOffset nicht so klar erkennen kann):
1) Du stellst mit LLC 5 im UEFI 1,5V ein, hast dann beim Booten auch 1,48V (Vdrop) anliegen und später in Prime 1,39V (Vdroop). Sieht auf den ersten Blick ungesund aus (1,48-1,5V beim Booten ist schon hoch, uiuiui), ist aber nicht problematisch, da ohne Last noch wenig Strom fließt und die CPU damit kaum beansprucht wird. Die Spannungspitzen (unsichtbar!) gehen dabei aber auch nur bis zu den eingestellten 1,5V im UEFI:
2) Stellst du dagegen mit LLC 2 im UEFI 1,4V ein, hast du beim Booten auch nur 1,395V anliegen und auch bei Prime geht die Spannung dann nur auf die 1,39V runter. Man könnte also denken dass das "gesünder" für die CPU ist, da wir ja nun nicht mehr auf 1,5V kommen, richtig? Genau das ist aber eben FALSCH, denn nun wirst du Spannungsspitzen (in CPU-Z unsichtbar!) bis weit über die 1,5-1,52V haben, die du bei LLC 5 gehabt hättest:
(Die UEFI VCore ist in der Skizze die "CPU VID", die zwar in dem Beispiel nur bei 1,25V ist... also nicht ganz zum Beispiel passt, aber es ist immer besser das anhand einer Skizze nochmal sehen zu können).
Das ist der Punkt, der zugegebenermaßen auch schwer zu verstehen ist, da man es in CPU-Z eben nicht sehen kann und 90% der Leute, die sich nicht ins Thema einlesen, daher davon ausgehen dass eine höhere LLC dann viel gesünder für die CPU ist (da in CPU-Z zu jedem Zeitpunkt - egal ob viel Last oder wenig Last bzw. beim Lastenwechsel, ein niedrigerer Wert angezeigt wird).
Dennoch hat LLC natürlich seine Daseinsberechtigung, gerade beim Lastenwechsel kann auch der Moment des Vdroops dann genau der Moment sein, in dem der Stresstest oder Benchmark dann crasht. Dies verhindert LLC natürlich dann effektiv (da es keinen Vdroop mehr gibt). Ergo... LLC kann sinnvoll sein und wird auch die CPUs nicht in unmittelbarer Zukunft zerstören (trotz unsichtbarer Spannungsspitzen), aber man sollte LLC aus den richtigen Gründen nutzen (und nicht nur weil es in CPU-Z auf den ersten Blick besser aussieht). Denn auch eine VCore von 1,5V im Idle oder bei Teillast ist ebenfalls nicht ungesund und wir die CPU auch nicht (bzw. langfristig betrachtet sogar eher weniger schnell) töten
P.S: Nur unter Last sollte die VCore dann natürlich nicht mehr weit über 1,4V sein
Günstige Low-Budget Boards haben bei der LLC oft nur on oder off. Je nach Board und Güte der Spannungsversorgung gibt es auch hier Unterschiede.
Die meisten OC-Boards legen mit Bios-Default Einstellungen 100% LLC an, was wohl zum Ausdruck bringen soll, dass es sich um ein Overclocker Board handelt, nicht weil das für den Dauerbetrieb zu bevorzugen ist.
Bei Low-Budget Boards, wo man nur zwischen on oder off wählen kann, bedeutet LLC on oft = max. Vdroop nach Intel Vorgaben.
Leider kann man hier nicht aus rein logischem Verständnis genau definieren, ob LLC on oder off wirklich on oder off ist.
Deshalb sollt man sich am Spannungsabfall unter Last orientieren, um sicher gehen zu können.
Bei OC Boards, wo man eine LLC Level Steuerung hat, reden wir Overclocker von LLC off, wenn man nicht mit der LLC gegen den Vdroop arbeitet, so wie es für den Dauerbetrieb von Intel vorgesehen ist.
Mit LLC Einstellung @ auto liegt bei den meisten Boards 0.02V mehr an als mit 100% LLC anliegen würde.
Auf den Asrock-Boards ist der LLC Level5 = off und läuft ohne Probleme, sehr weit.
Auf den Asus-Boards ist der LLC Level1 = off. Bei vielen Asus-Boards empfiehlt es sich relativ früh leicht in die LLC zu gehen, um Stabilität zu erreichen.
Auf den Gigabyte-Boards macht sich die LLC Stufe High (~50%) sehr gut. Bei kleineren LLC Stufen oder off, kommt es nach ~ 1h testen zu Problemen.
Auf den MSI sind die verschiedenen LLC Stufen in % von 5-100%. Auf einigen MSI-Boards ist 12,5% die kleinst mögliche LLC Stufe.
Die Load Line Calibration regelt man auf den MSI-Boards unter OC-DigitALL PowerCPU Vdrop Offset Control.
Die LLC Stufe off ist für ein 24/7 Setting zwar zu bevorzugen, aber letztlich muss man das machen was je nach Board/CPU und angestrebten Takt nötig bzw. am besten ist.
1.2 Eingangsspannung VRin/Input-Voltage:
Es gibt eine Regel die besagt, dass eine kleinere Differenz als 400mV zwischen der Eingangsspannung und der Vcore zu Instabilität führt und nicht gut für die CPU ist.
Die Eingangsspannung soll unter Luft bis zu 2.4V unbedenklich sein.
Da solche Angaben meistens aus der Bencher-Szene stammen, sollte man hier zur Sicherheit besser unter 2V bleiben.
Da die Load Line auf die Eingangspannung wirkt und man unter Last @ LLC off einen starken Spannungsabfall hat, dürften knapp unter 2V wirklich unbedenklich sein.
Bei den meisten Chips, die ich hatte, ist z.B. bei 4.5GHz eine Eingangsspannung/Vrin 1.88-1.90V LLC off ausreichend.
Die neuen Devil's Canyon scheinen auf manchen Boards mit reichlich weniger Eingangsspannung auszukommen und auch mit den anderen Spannungen etwas genügsamer zu sein.
Allem Anschein nach hat sich hierzu mit den neuen Bios-Versionen und deren neue Management Engine etwas geändert, was evtl. auch bei den ersten Haswell eine kleinere VRin möglich macht.
Man sollte sich trotzdem besser an die Regel halten und die Differenz zwischen VRin und Vcore nicht kleiner als 400mV werden lassen.
Bei höherem Takt steigt auch die Eingangsspannung und es kann sein, dass man ab einem gewissen Punkt und Board nicht mehr mit LLC off klarkommt.
Für ein 24/7 Setting ist die Load Line Calibration = off zu bevorzugen, es sein denn man hat einen Chip oder Board wo sich LLC off schwierig gestaltet.
Mit den guten Chips konnte ich auf dem Z87M OCF bis 4800MHz im LLC Level5 = off bleiben.
Mit dem sehr guten 4670K sogar bei 4900MHz noch LLC = off bei 1.95V, die im Dauerbetrieb sicher weniger belasten als z.B. 1.90V mit 100% Load Line.
Eine zu hohe, sowie eine zu niedrige Eingangsspannung ist schlecht. Die Input muss genau stimmen und der richtige LLC-Level spielt hier auch eine wichtige Rolle.
Falls man einen Chip erwischt hat der generell viel Vcore benötigt, oder in solche Regionen takten möchte, braucht man dementsprechend mehr Input-Voltage.
Mit fixed eingestellter Eingangsspannung komme ich am besten klar.
1.3 VRing/Cache-Voltage
Früher unter dem Begriff Northbridge bekannt, wird der Uncore-Takt in CPU-Z immer noch so genannt.
Man sollte vorerst mit Standard Uncore-Takt arbeiten. Bei den i5 4670K ist der Standard Uncore-Takt 3800MHz und bei den i7 4770K 3900MHz.
Bei den Devils Canyon 4790K geht der Standard Uncore-Takt bei 4000MHz los.
Ein höherer Uncore-Takt kann sich sehr schwierig gestalten. Alles über 4000MHz Uncore bringt nur noch in Synthetischen-Benchmarks Vorteile.
Hier muss jeder selbst entscheiden, ob einem der Mehraufwand und die höhere Cache-Voltage es wert sind.
Die besseren Chips die ich bisher hatte, kommen bei einem Uncore-Takt von 4200MHz mit einer Vring/Cache-Voltage von 1.131-1.139V aus.
Bei höherem CPU-Takt steigt ab einem gewissen Punkt, meistens höher als 4800MHz dann auch die Vring/Cache-Voltage und bei höherem Uncore-Takt steigt die Cache-Voltage wiederum.
Nicht jeder Chip macht spielend einen hohen Uncore-Takt, die meisten werden jedoch mit 4200MHz Uncore keine Probleme haben, das ist aber kein muss.
Zur Uncore gibt es eine Regel die besagt, dass man optimaler weise mit dem Uncore-Takt 300MHz unter dem Core-Takt bleiben sollte.
Hier ist aber zu bedenken, dass ein Uncore-Takt über 4200MHz sehr schwierig sein kann.
Asus-Boards sollen Probleme haben, großere Differenzen zwischen Core-Takt und Uncore-Takt zu realisieren.
Es ist zu hoffen, dass hier mittels neuen UEFI-Versionen Abhilfe geschaffen wird/wurde.
Ich empfehlen jedem User, der die 4.5GHz CPU-Takt anstrebt, es zuerst einmal mit geringem Uncore-Takt zu versuchen.
Es sei denn, man hat auch mit Standard Uncore Probleme, dann sollte man besser versuchen die 300MHz Differenz zu realisieren.
Bei Standard Uncore sollte die Cache-Voltage zwischen 1.10 und 1.14V gut gewählt sein.
Mit den neuen Devils Canyon berichten einige User bei 4000MHz Uncore mit einer Cache-Voltage von 1.05V auszukommen.
Für ein 24/7 Setting ist eine höhere Cache-Voltage als 1.20V nicht zu empfehlen.
Auch die Cache-Voltage macht sich am besten im Override Modus.
Bei einem Minimum an Vcore und höherem Core/Uncore-Takt, muss bei mir die Cache-Voltage auf's mV genau stimmen.
Auf den meisten Systemen macht sich etwas mehr VRing als mindestens nötigt sind, am Anfang sicher nicht schlecht.
1.4 Vcore und der richtige Modus:
Ein wesentlicher Aspekt zur Load-Vcore im Dauerbetrieb ist die VID. Ein Chip mit hoher VID bleibt viel kühler, als Chips mit kleiner VID.
Bei einem Chip mit kleiner VID ist zwar oft das OC-Potenzial höher, um dauerhaft hohe/n Vcore/Takt fahren zu können ist eine exzellente Kühlung nötig.
Haswell CPUen sollen problemlos 1.4V ab können, aber hier sind die Temperaturen meistens, schon lange bevor man überhaupt in die Nähe dieser Voltage käme, der limitierende Faktor.
Im Allgemeinen werden dieses Chips sehr heiß und eine Vcore Richtung 1.3V sorgt schnell dafür, dass man bei 80°C Kerntemperaturen landet.
Die meisten Haswell sind ungeköpft kaum zu bändigen. Ab 65° Kerntemps kann das Ergebnis schon verfälscht werden.
Man kann die Chips modifizieren, die original Intel TIM gegen eine bessere Wärmeleitpaste tauschen.
Zum Thema CPUen-Köpfen/Modifizieren hier der richtige Thread: Intel Ivy Bridge & Haswell geköpft - Erfahrungen ohne HS bzw. mit gewechseltem TIM
Falls die Enthauptung best möglich erledigt wurde, sind bis zu 30°C besser Kerntemps keine Seltenheit und dann geht natürlich was.
Bei den Haswell und Devils Canyon Chips hat man drei Vcore-Modi zur Auswahl - Adaptiv- Override- und Offset- Vcore-Modus.
Auf den Asrock-Boards kann man nur zwischen Adaptiv oder Override wählen. Offset ist immer präsent, nur muss man sich über den Sinn Gedanken machen.
Auf einigen Asus-Mainboads kann man auch einen reinen Offset-Modus wählen.
Im adaptiven Modus ist es nicht möglich die minimal nötige Vcore zu realisieren, was durch den AVX Aufschlag entsteht.
Auf den Asrock-Mainboards kann man im Override-Modus, die Offset auf auto lassen. Bei den Asrock-Boards funktioniert das hervorragend, ohne Aufschläge.
Zur Sicherheit kann man hier den Aufschlag +0.005V einstellen, um sicher zu gehen, dass das Board hier nicht zu viel drauf packt.
Diese 5mV sollte man deshalb nehmen, da auf dieser Plattform nur 5mv Schritte einen Effekt in den Monitorring-Tools wie CPU-Z bewirken.
Auch für die Cache-Voltage ist eine Offset-Einstellung vorhanden und unterliegt den gleichen Regeln.
Mit Offset kann man die Vcore ins positive oder negative beeinflussen, relativ zur VID.
Falls man Probleme mit Abstürzen im Idle/Teillast hat, könnte man schauen, ob man diese durch positives Offset in den Griff bekommt.
Das wäre z.Z. der einzige Sinn mit Offset im Override Modus, den ich auf dem Asrock Z87M OCF erkennen konnte.
Da der adaptive Vcore-Modus auf allen Boards überhaupt nicht geht, ohne bereits mit AVX mindestens 50mV mehr Vcore als nötig zu haben, habe ich mich damit nicht weiter befasst.
Der adaptive Vcore-Modus macht wahrscheinlich nur @ default Sinn. Die automatisierten Aufschläge sollen wohl alle Eventualitäten berücksichtigen.
Genau wie bei vorgewählten OC-Profilen, wo mit den Spannungen gerne übertrieben wird, wird hier unnötig viel angelegt.
Falls man die Chips mit dem neuen Befehlssätzen AVX2/FMA3 testet, braucht man wiederum mehr Vcore.
Override hat absolut nichts mehr mit der fixed Vcore vergangener Plattformen zu tun, deshalb sollte man sich von dem Begriff fixe Vcore völlig verabschieden, Override nehmen und sich über ein besseres Ergebnis freuen. Zumindest bei den Mainboards wo man nur zwischen Adaptive und Override wählen kann und Offset nicht als eigenständiger Vcore Modus zu nutzen ist.
Der Adaptive Vcore Modus ist @ default auf den meisten Mainboards ausgewählt, aber durch den enormen AVX Aufschlag ist das beim testen mit Prime95 nicht die richtige Wahl.
Haswell hat die modernsten Energiesparfunktionen und schaltet sogar ganze Kerne ab.
Die Monitorring Tools wie CPU-Z zeigen im Override zwar oft unter Last wie im Idle die gleiche Vcore an, was aber kein Problem ist.
Das liegt technisch daran, dass hier die VID von Core 0 und nicht die Vcore ausgelesen wird. Die verschiedenen Kerne haben alle eine eigene VID.
Keine Angst, man spart im Idle trotzdem Energie und die Spannung wird auch im Idle gesenkt, nur meistens nicht richtig von CPU-Z angezeigt.
Auf einigen Mainboards wird es richtig ausgelesen, sogar die gesenkte Vcore im Override Vcore Modus auch mit CPU-Z, auf den meisten Boards eben nicht.
Bei ASRock zeigt das Board eigene Monitoring Tool - Formula Drive oder A-Tuning, die gesenkte Vcore im Idle, auch im Override-Modus an.
Leider zeigt A-Tuning es auch nicht bei jedem Board korrekt an und es wurde auch schon berichtet, dass User es mit ihrem Board mit keinem Tool richtig angezeigt bekommen.
Es ist letztlich auch egal, denn diese User bekommen nur die VID angezeigt und sollten sich da endlich auf die Aussagen anderer verlassen.
Mit einem Energieverbrauchsmessgerät kann man es immer nachvollziehen.
Meine Messung mit Bios-Defaults (Adaptiver Modus) oder 4800MHz@ 1.224V im Override ergibt jeweils 57Watt im Idle.
Die meisten Mainboardhersteller setzen das Konzept mit den Vcore-Modi genauso wie Asrock um, dann ist Override am besten.
Der reine Offset-Modus, der auch eine sofortige Absenkung der Vcore im Idle in CPU-Z zulässt, macht gemessen keinen Unterschied zu Override und ist nicht mit jedem Board möglich.
Warum das Konzept mit den Vcore-Modi verschieden umgesetzt wird ist spekulativ.
Asrock interpretiert es halt so, dass man keinen reinen Offset-Modus nutzen kann.
Da bei Asrock Hardwaredesigner wie Nick Shih tätig sind, dessen Hauptaugenmerk auf guter OC-Performance liegt, kann man davon ausgehen, dass die Interpretation und Implementierung in den UEFIs passt.
Die Vcore wird auch im Override gesenkt, nach längerem Idlen sogar extrem, nur nicht immer korrekt von CPU-Z angezeigt.
Grundsätzlich ist es egal welcher Modus genutzt wird, außer adaptiv, da hier durch AVX oder AVX2/FMA3 viel mehr Vcore im Load anliegt als nötig.
Die Energiesparfunktionen müssen an sein, damit man auch ohne Last (im Idle) Energie spart und die greifen im jedem Modus, egal was von Monitoring Tools angezeigt wird.
EIST und C1E sollten sowieso aktiv sein und der C-State C3 für das Absenken auf ca. 0.8V, C6+C7 für das Absenken auf nahe 0V, durch die Kernabschaltung.
Die Tatsache das im Idle ganze Kerne deaktiviert werden, macht den Vcore-Modus Override absolut alltagstauglich.
Mit HWiNFO könnte es auch angezeigt werden.
Hier ein weiteres Beispiel des Users suali mit gesenkter Idle-VID/Vcore im Override und die Anzeige der verschiedenen CPU-Z Versionen.
Ausgangsszenario:
x45 bei 1,225 angelegt im UEFI per Override, LLC auf 5% (MSI), Offset-Settings auf AUTO.
Messergebnisse bei Prime95 1344k Run:
CPU-Z Standard: 1.71.1 (x64)
CPU-Z Gigabyte OC Version: 1.71.1 (x64)
Aida64 CPUID: 4.70.3200
MSI Command Center: 1.0.0.84
Im Load:
Im Idle:
Kurz um:
- CPU-Z: 1.248 (last) / Dropped im Idle
- CPU-Z Gigabyte OC: 1.224 konstant im Idle/Load. Wert verändert sich nicht
- Aida64 CPUID: 1.248 (last) / Dropped im Idle
- MSI Command Center Sensor: Version: 1.248 (last) / Dropped im Idle
- Messung per Multimeter direkt am Mainboard (Core0) = 1228-1230 unter Last. Im Idle wird wunderbar Vcore gesenkt.
Je nach CPU-Z oder Sensor-Tool wird der per Override gesetzte Vcore Wert (plus minus 0,001) konstant angezeigt oder ein Wert, der in diesem Fall um glatte 0,023 drüber liegt übern UEFI-Setting.
An der direkten Messung sieht man, dass die CPU seeehr sauber runter taktet im Idle und unter Last liegen die Werte an die man eingestellt hat (in dem Fall bis zu +0,005 höher. Offset und so).
1.5 Ram Takt/Vdimm:
Der Ram-Takt und die Vdimm sind immer ein Kompromiss aus Leistung und Effizienz.
Das Ram-Setting testet man mit MemTest. Hier gibt es die Dang Wang Version mit MemTest 4.3.0: Dang Wang RunMemtestPro 4.3.0.rar beim Filehorst - filehorst.de
Im Allgemeinen hat man auf dieser Plattform mit einem 2400MHz Ram-Takt das Optimum an Performance erreicht.
Mit Können und der richtigen Ram/Mainboard-Kombi, kann man durchaus auch ein sehr gutes 2600MHz Setting erzielen.
In den Intel white papers wird eine Vdimm mit 1.575V angegeben, was aber eher für die 1333/1600MHz Module gelten dürfte.
1333 oder 1600er Kit's kommen oft mit 1.5Vdimm daher und aus. Diese dürften für Gamer und Overcklocker aber eher uninteressant sein.
Der größte Teil der Ram-Kit's kommen mit 1.65Vdimm im XMP daher und die meisten 2x8GB Kit's werden bei 2400MHz Takt auch nicht mit viel weniger auskommen, sehr gute Kit's evtl. um die 1.6V.
Bei den 2x4GB Kit's sieht das anders aus. Hier gibt es gute Kit's die 2400MHz Takt mit wenig Vdimm von 1.50-1.520 schaffen.
Dazu muss die CAS-Latency allerdings mit CL9 Kit's auf CL10 erhöht werden.
Bei den Intel-Systemen bringt Takt mehr als Timmigs.
Man kann also auch eine kleinere Vdimm als 1.65V bei sehr guter Performance und hohem Ram-Takt realisieren, teilweise sprechen die CPUen darauf sogar positiv an.
Der Ram-Speicher sollte innerhalb der Spezifikationen laufen und nicht zu Fehlern führen.
Ram-OC macht die Sache natürlich nicht einfacher und kann sich auf der Vcore und SA/VTT bemerkbar machen, was aber erst ab 2000MHz Auswirkungen haben sollte.
Eine Ram-Vollbestückung kann etwas mehr Agent/IMC Voltage nötig machen, eventuell auch mehr Vcore.
Ein kleinerer Ramtakt als 1866MHz sorgt auf der Haswell Plattform für einen nicht unwesentlichen Performance-Verlust, welches in Spielen je nach Takt bis zu 10 Frames ausmachen kann und deshalb die Spieler interessieren sollte.
Hierzu ein interessanter Test: Haswell Real World Performance: DDR3-1600 RAM Speed Is Not Enough - hwbot.org
Dass man bei Ram-OC seine Rams im Griff haben sollte, dürfte klar sein.
Die VTT und Agent/IMC-Voltage spielt dann hier auch keine unwichtige Rolle.
Die VTT auch CPU analog/digital I/O Voltage Offset genannt, stellt man am besten asynchron ein.
Viele User berichten zwar mit auto - Einstellungen auf der Agent und VTT sehr weit zu kommen, aber das hängt wohl auch stark vom Ram und Board ab.
Ich muss mit meinen G.Skill TridentX-F3-2400C9Q-16GTXD @ 2400MHz 10-11-11-21-1T auf dem Z87M OCF eine Agent von +0.016 fahren und eine VTT a/d von +0.030 und +0.025.
Mit den Samsung Green @ 2400MHz war die VTT gleich, aber die Agent etwas höher nämlich +0.018.
Die Agent und die VTT wirken beide auf den IMC, deshalb nicht nur die VTT alleine erhöhen, sondern auch die Agent gleich erhöhen.
Das ist bei 2400MHz Ramtakt ein muss. Das war auch schon auf der Vorgängerplattform so.
Bei 2400MHz Ramtakt sollte die Agent zwischen +0.015 bis +0.020 liegen und die VTT zwischen +0.025/+0.020 bis +0.030/+0.025 auf dem ASRock.
Ist die optimale SA und I/O offset einmal gefunden, passen diese bis zu einem gewissen Punkt auch bei einem anderen CPU-Takt.
Die richtige SA und VTT ist wichtig! Auf Auto-Einstellungen legen die Z87 Boards auf der SA +0.230 und auf der VTT +0.200 an, was grenzwertig und unnötig ist.
Auf den Z97 soll die SA/VTT @ auto auf einigen Boards nicht mehr so hoch angesetzt werden, dennoch setzt man den Wert auch hier besser manuell.
1.6 Ausgangswerte der VTT und Agent:
Auf Asrock hat sich folgendes bewährt: VTT analog/digital Offset = analog 5mV höher als digital einstellen - Agent ab 2400MHz Ram zwischen +0.010 und +0.020
Auf den meisten Asus hat sich folgendes bewährt: VTT analog/digital Offset = digital 50mV höher als analog einstellen - Agent ab 2400MHz Ram zwischen +0.050 und +0.088
Einige User berichten auf ihrem Asus ähnliche Werte wie auf den Asrock zu fahren, nämlich 5mV mehr auf der analogen VTT und auch mit einer kleinen Agent aus zukommen.
Auf MSI sollte man es ruhig wie bei den Asrocks handhaben.
Auf Gigabyte Boards sollen oft synchrone Werte auf der VTT gut sein.
Mit den neuen Devils Canyon sollte man auf einem Z97 Board ruhig auch versuchen mit weniger SA und VTT auszukommen.
1.7 Maximale Voltage-Werte bei Haswell laut Gigabyte-Forum (Bencher-Szene):
Vrin = Input = 2.4V
Vring = Cache = 1.35V
Vcore = 1.45V
SA = Agent = +0.23V über Standard
I/O = VTT = +0.20V über Standard
PCH = 1.15 - 1.20V
DRAM = Vdimm = 2.15V
2.0 Vorbereitungen:
Nachdem man sein System mit Bios-Default-Einstellungen überprüft hat und man sicher ist, dass die CPU i.O. ist und auch der Ram läuft wie er soll, sollte man mit einem moderaten Takt anfangen zu testen.
Leider packt nicht jeder Haswell die 4.5GHz, aber das dürfte man schnell feststellen.
Die minimal nötige Vcore um sauber ins Windows zu booten wird für Prime nicht reichen, hier muss man erfahrungsgemäß zwischen 15-70mV drauf geben.
Mit der Input/Cache solltet ihr euch zunächst an sinnvollen Werten anderer für den gewünschten Takt orientieren.
Je nach Board und deren Eigenheiten tut man gut daran sich zu informieren, wie es bezüglich der VTT und Agent bestellt ist und welche Ausgangswerte hier sinnvoll sind.
Die VTT und Agent wirken beide auf den Ram/IMC, deshalb ist man hier vielleicht gut beraten, gleich beide anzuheben.
Bei Einstellungen der SA und VTT @ auto, legen die Boards viel zu viel an und das muss nicht laufen.
2.1 Prime95
Lange Zeit war das Testen mit der Prime95 Version 27.9 AVX stable aktuell und ausreichend.
Seit Haswell wird von AVX2 gesprochen: AVX2 im Detail: Der erweiterte Befehlssatz für Ivy-Bridge-Nachfolger Haswell
Die Prime95 Version 27.9 reichte grundsätzlich für alle möglichen Szenarien und die Listen-Threads wurden mit dieser Version geführt.
Die Zeit bleibt nicht stehen.
Die neuen Prime95 Versionen haben Vorteile.
1.) Die Stress-Routinen wurden auf moderne Chips angepasst.
2.) Die verkürzte Run Time der FFT-Tests stellt eine große Verbesserung dar, was nicht nur mit Blick auf das Sparen von Ressourcen richtig ist.
3.) Die Verkürzung der FFT Run-Time auf 3min bzw. 6min, sorgt für kürzere Phasen der sehr stark belastenden small FFTs im Bezug auf deren enorme Hitzeentwicklung.
4.) Ich konnte auch eine höhere Sensibilität der neueren Versionen feststellen. Bei selektiven Tests erfolgten Aussteiger einzelner Worker schon nach 2min, die bei gleichem Szenario mit der Version 27.9 erst nach 10min erfolgten.
Neuste Prime95 Versionen GIMPS - Free Prime95 software downloads - PrimeNet
Prime95 Version 29.8 build 6
Mit der Version 27.9 dauert ein kompletter Durchlauf/Full Custom AVX ~ 21h bei 82 FFT-Tests x 15min rechnerisch 1230min.
Mit der Version 29.4 dauert ein kompletter Durchlauf/Full Custom AVX ~ 5,5h bei 79 FFT-Tests x 3min rechnerisch 237min.
Mit der Version 29.8 dauert ein kompletter Durchlauf/Full Custom non AVX ~ 11h bei 88 FFT-Tests x 6 Min. rechnerisch 528 min.
Real variiert die Länge der Laufzeit des Full-Custom Runs, weil im Windows noch andere Prozesse Ressourcen an Rechenleistung benötigen.
Die verkürzte Zeit spart nicht nur Nerven sondern auch Energie.
Prime95-Verlauf Version 27.9 (AVX)
448k, 8k, 512k, 12k, 576k, 18k, 672k, 21k, 768k, 25k, 864k, 32k, 960k, 36k, 1120k, 48k, 1200k, 60k, 1344k, 72k, 1536k, 84k, 1728k, 100k, 1920k, 120k, 2240k, 140k, 2400k, 160k, 2688k, 192k, 2880k, 224k, 3200k, 256k, 3456k, 288k, 3840k, 336k, 400k, 480k, 10k, 560k, 16k, 640k, 20k, 720k, 24k, 800k, 28k, 896k, 35k, 1024k, 40k, 1152k, 50k, 1280k, 64k, 1440k, 80k, 1600k, 96k, 1792k, 112k, 2048k, 128k, 2304k, 144k, 2560k, 168k, 2800k, 200k, 3072k, 240k, 3360k, 280k, 3584k, 320k, 4000k, 384k, 4096k, - random
Prime95-Verlauf Version 29.4 build 8 (AVX)
384K, 8K, 448K, 12K, 512K, 16K, 576K, 20K, 672K, 24K, 768K, 28K, 864K, 35K, 960K, 40K, 1152K, 50K, 1344K, 64K, 1536K, 80K, 1680K, 96K, 1792K, 112K, 2048K, 128K, 2400K, 144K, 688K, 168K, 3072K, 200K, 3360K, 240K, 3584K, 288K, 336K, 400K, 10K, 480K, 15K, 560K, 18K, 640K, 21K, 720K, 25K, 800K, 32K, 896K, 36K, 1024K, 48K, 1280K, 60K, 1440K, 72K, 1600K, 84K, 1728K, 100K, 1920K, 120K, 2304K, 140K, 2560K, 160K, 2880K, 192K, 3200K, 224K, 3456K, 256K, 3840K, 320K, 4032K, 4096K, - random
Prime95-Verlauf Version 29.8 build 6 (non-AVX)
192K, 4K, 224K, 240K, 5K, 256K, 288K, 320K, 6K, 336K, 384K, 400K, 8K, 448K, 480K, 10K, 512K, 560K, 576K, 12K, 640K, 672K, 720K, 14K, 768K, 800K, 16K, 896K, 960K, 1024K, 20K, 1120K, 1152K, 1200K, 24K, 1280K, 1344K, 28K, 1440K, 1536K, 1600K, 32K, 1680K, 1728K, 1792K, 40K, 1920K, 2048K, 48K, 2240K, 2304K, 2400K, 56K, 2560K, 2688K, 2800K, 64K, 2880K, 3072K, 72K, 3200K, 3360K, 3456K, 80K, 3584K, 3840K, 4096K, 84K, 4480K, 4608K, 96K, 4800K, 5120K, 5376K, 112K, 5600K, 5760K, 6144K, 128K, 6400K, 6720K, 144K, 6912K, 7168K, 7680K, 160K, 8000K, 8192K, - random
Seit den Versionen 28.x wird der Befehlssatz FMA3 angesprochen. Auf der Haswell-Plattform benötigt man dazu ~ 50mV mehr Vcore über dem AVX stabilen Wert.
Es ist von Intel nicht vorgesehen diese Chips dauerhaft auf allem Kernen mit FMA3 Befehlssatz zu stressen.
Programme wie Intel Extreme Tuning Utility XTU sprechen nur kurzzeitig einzelne Kerne mit FMA3 an.
Deshalb sollte man auf Haswell und Devils Canyon beim Testen mit der Prime95 Version 29.4 den Befehlssatz FMA3 deaktivieren.
Dazu muss man den Befehl CpuSupportsFMA3=0 in der local.txt Datei setzen und diese schreibgeschützt machen.
Man muss die Prime-Instanz einmal gestartet haben, damit die local.txt Datei entsteht.
Der Verlauf der FFT-Tests ändert sich, wenn man Befehlssätze wie FMA3 oder AVX deaktiviert.
Seit den ersten Six-Core Chips für Mainstream Sockel 1151, sowie des Sockel 2066, wird das Testen von Prime95 ohne AVX wieder Mode und reicht auch für meisten Anwendungen und Spiele.
Seit der Prime95 Beta Version 29.5 build 9 braucht man nun keine Befehlssätze mehr in der Local.txt zu deaktivieren, kann dies direkt im Programm wählen.
Mit AVX2 (fused multiply-add) deaktiviert man den Befehlssatz FMA3.
Neuerung: jetzt kann man gleich im Programm AVX512 - AVX2=FMA3 - AVX abwählen.
Mit den neuen Management Engine Interfaces und den neuen Prime-Versionen empfehle ich, sich nicht mehr mit sehr langen selektiven Tests einzelner FFTs abzugeben, sondern zu versuchen schnellst möglichen einen Prime-Custom Run zu absolvieren.
Selektives Testen einzelner FFT-Test ist nach wie vor die richtige Methode, um sich den optimalen Spannungen zu nähern, mehrmals passed a 3min bzw. 6min dürfte reichen.
Bis Kabylake wurden Listen-Runs mit der Version 27.9 mit 1.5h Mindestlaufzeit geführt.
Seit Skylake-X und Coffeelake S/R wird die Version 29.4 build 8 genutzt und die Laufzeit auf 45min verkürzt und auch non AVX-Runs gelistet.
Gerade was das Verschwenden von Ressourcen angeht, ist das eine zeitgemäße Entscheidung.
Windows7 muss das Service Pack 1 integriert sein, sonst wird der Befehlssatz AVX nicht angesprochen.
Prime95 32Bit Versionen machen nur Sinn, wenn man ein Betriebssystem in 32Bit Variante nutzt.
Anderen Falls macht man sich selbst etwas vor, denn Prime95 in 32Bit auf einem 64Bit Betriebssystem braucht weniger Vcore, als wirklich nötig.
Davon abgesehen ist die Speicherverwaltung in 32Bit Betriebssystemen auf 3.5GB limitiert.
Ältere Prime-Versionen wie 26.6 fordern moderne Chips wie Haswell nicht mehr ausreichend, um Aussagen über die Stabilität treffen zu können.
Für selektive Tests wählt man Custom, stellt links wie rechts im Fenster min-FFT und max-FFT den entsprechenden FFT-Test ein, z.B. 800K für Ram, setzt den Hacken "Run FFTs in-place" - Feuer frei...
Voltages mit einzelnen FFT-Tests identifizieren
1344K = Vcore
448K = Vrin/Input
512 u. 576K = Cache/Uncore
672-720K = VTT/ IO-Voltage
768K = Agent/IMC
800K = Vdimm/Timings
864K = hier spielen alle Komponenten hinein
Einen Custom-Run startet man mit den Standard-Einstellungen z.B Version 27.9 von 8-4096K "Run FFTs in-place".
Die Reihenfolge des Ablaufs der FFT-Tests, sowie die Run-Time unterscheiden sich zwischen den Versionen.
Der Custom Run belastet durch die ständigen Wechsel zwischen small und large FFTs etwas härter, als es beim selektiven Testen der Fall ist.
Falls man Prime unbeaufsichtigt laufen lässt und es im Test-X ausgestiegen ist, kann man im results.txt sehen bis wohin Prime gelaufen ist.
Der letzte passed aller Kerne wird angezeigt und logischerweise ist es dann im darauf folgendem Test ausgestiegen, oder ein Kern oder mehrere Kerne haben den passed nicht geschafft.
Es gibt zwei verschiedene Ergebnisse des Custom-Run mit Prime95.
Als erstes der sogenannte Listen-Run, der sich mit möglichst wenig Vcore am besten eignet, um schnellst möglich ein vergleichbares Ergebnis zu erzielen.
Als zweites das sogenannte rockstable Setting, welches am besten durch den Full-Custom-Run "ein kompletter Durchlauf" untermauert wird.
Der sogenannte Custom-Run sollte mindestens 2,5h durchhalten, um von einer Alltagsstabilität ausgehen zu können.
Prime95 ist nur eines von vielen Stabilitätstest-Programmen, aber sehr aussagekräftig.
Der große Vorteil von Prime95 ist, dass man gezielt alle Spannungen abstecken/loten kann.
Alle Prime95 Versionen
3.0 Kurzanleitung:
Am Anfang schätzt man Voltages wie die VRin und VRing.
Die VRing kann zu Anfang ruhig etwas höher als nötig eingestellt werden.
Mit dem Ram-Setting auf sichere Werte gehen und genügend Vdimm einstellen. Zu Anfang besser etwas mehr als zu wenig einstellen.
Wenn man eine stabile Basis hat, kann man sich mit dem Ram-Setting noch genauer befassen.
Mit der SA und VTT an Werten anderer, je nach Ram/Takt und Board, orientieren.
Hierzu wurden ein paar Kombis für 2400MHz Ram-Takt und verschiedene Boards erwähnt.
Wenn man mit einer Vcore X ins Windows kommt, ist diese entweder schon gut geschätzt, oder man muss die Vcore für Prime erhöhen.
In der Regel braucht es mindestens 20mV mehr Vcore, eher mehr für Prime, als die kleinst mögliche bootbare Vcore.
Falls es jetzt zu Aussteigern kommt, kann man an Hand der BSOD's deuten woran es liegt.
Symptome sind weiter unten erklärt.
Man variiert so lange die Vcore/VRin bis 1344K mindestens 30min = 2x passed läuft.
Wenn jetzt 448K 1x passed im Custom läuft, steht die Eingangsspannung vorerst.
Falls es später im Custom Run zu Reboots ohne Blusscreen kommt, muss man die Eingangsspannung erneut erhöhen.
Nun testet man die VRing/Cache/Uncore bis 512K und 576K mindestens 30min = 2x passed laufen.
Optimaler weise checkt man jetzt die SA/VTT genauer.
Ab wann man einen mehrstündigen Custom Run wagen kann, sollte jeder für sich entscheiden.
Ein ausgiebiges selektives Testen, ist bei Problemen auf jeden Fall nötig. Um optimale Ergebnisse und Stabilität zu erreichen ist das kein Luxus.
3.1 Ausführliche Anleitung:
Man testet zuerst mit 1344k, weil hier die anderen Faktoren am wenigsten hineinspielen, deshalb ist es die beste Methode sich der richtigen Vcore zu nähern.
Man muss systematisch vorgehen. Essenziell bei Haswell ist die Eingansspannung/Input.
Zu aller erst muss die 1344K mindestens 30min in Verbindung mit der richtigen Vcore/Input im richtigen LLC Level stehen, bevor man die anderen Voltages weiter eingrenzen kann.
Am Anfang im Näherungsverfahren macht es noch nicht viel Sinn, die Vcore länger als 30min laufen zu lassen.
Die 864K kommt am härtesten und braucht mehr Vcore als 1344K, was aber erst für ein rockstables Setting relevant wird.
Im Näherungsverfahren ist man evtl. besser beraten, mit der Vcore noch am unteren Limit zu bleiben, um zu verhindern, dass man mit der Vcore evtl. andere Spannungen deckelt.
Deshalb sollte man zuerst einen Listen-Run mit möglichst wenig Vcore hin bekommen. Um mit möglichst wenig Zeitaufwand vergleichen zu können, ist der Listen-Run nach wie vor sinnvoll.
Wenn dann 1344K mindestens 30min durchhält, sollte die Eingangsspannung auch schon halbwegs passen, oder sie stimmt sogar schon.
Um die Input dann genauer zu prüfen sofort den Custom-Run starten, falls es durch 448K läuft steht die Input vorerst, oder man muss erneut nach korrigieren, oder den LLC Level anpassen.
Jetzt kümmert man sich um die Cache-Voltage, die auch jeweils 30min durchhalten sollten. BSODs und Symptome sind weiter unten aufgeführt.
Manche Chips reagieren sehr empfindlich auf der Cache-Voltage. Falls es sich sehr schwer gestalten sollte, die richtige Input zu finden, kann eine falsche Cache-Voltage daran schuld sein.
Dazu gehört dann Feingefühl, auch gleich andere Voltages einzuschränken, wenn man von der Testreihenfolge her irgendwo nicht weiter kommt.
Es gibt auch Chips die deutlich mehr Cache-Voltage benötigen, wobei auch eine höhere Differenz als 300-500MHz zwischen CPU- und Uncore-Takt hinderlich sein kann.
Die User die ihren Ram mit Standard 1600MHz laufen lassen und die Agent und VTT auf auto lassen, können sich 720-768-800K evtl. sparen.
Bei den meisten Systemen mit höherem Ram-Takt ist es sicher von Vorteil, die I/O Offset = VTT und System Agent gleich auf sinnvolle Ausgangswerte zu setzen.
Wer Rundungsfehler auf einzelnen Kernen hat, kommt nicht um die Anpassung der SA und I/O Offset = VTT herum.
Die Ausgangswerte für die Agent und VTT können je nach Board und Ram variieren. Ich halte generell nichts davon solche wichtigen Einstellungen auf auto zu lassen, ganz davon abgesehen, dass diese @ auto viel zu hoch sind. Wer sich mit allen wichtigen Spannungen auseinandersetzt, kann höchstwahrscheinlich einiges an Vcore sparen.
Falls es Probleme beim finden der Cache / SA und VTT gibt, tut man gut daran diese Tests selektiv länger zu testen. Bis zu 90min ist dann nicht verkehrt, um sicher zu gehen.
Wenn die Vdimm bei mir nicht reicht, gibt es Neustarts nach über 45min, beim selektiven Testen von 800K.
Bei Haswell kann man bevor man den Custom Run startet, den Vcore-Test 1344K auch etwas länger laufen lassen, bis zu 1.5h, bei manchen Chips steht die Vcore dann zu 99,99%, zumindest für einen 2-4h Run.
Das ist aber leider nicht bei jedem Chip eine Garantie, dass die Vcore schon fast 100% steht. Ich hatte Chips hier, die mit 30min getesteten 1344K einen Listen-Run schaffen, aber andere wie weiter unten in Eigenarten beschrieben nicht. Wer bereits alle wichtigen Spannungen wie die Vcore/Input/Cache und SA/VTT abgesteckt hat und jetzt im Custom-Run die kleinen FFTs 8-12-18K nicht wollen, liegt das wie in Eigenarten beschrieben, nur noch an der Vcore. Bis hierhin sollte euer Setting für einen Listen-Run reichen, welche hier im Intel Haswell & Devil's Canyon (Sockel 1150) OC-Ergebnis-Thread gepostet werden können:
Ich empfehle zwar am Anfang im Näherungsverfahren mit der Vcore noch am unteren Limit zu bleiben, um zu verhindern, dass man mit der Vcore andere Spannungen deckelt, dennoch muss die Vcore ausreichend sein.
Leider gibt es auch Chips bei denen es besser ist, sich nicht zu viel mit den 1344K zu beschäftigen.
Für einen Listen-Run mag ein 1344K Setting noch ausreichend sein, aber für einen mehrstündigen Custom-Run oder ein rockstables Setting braucht es eh mehr Vcore.
Bei sehr schwierigen Chips, bei denen wirklich alle Nebenspannungen genau stimmen müssen, kann es vorkommen, dass man sich sehr schwer tut nach der empfohlenen Vorgehensweise klar zukommen.
Gerade bei solche problematischen Chips empfiehlt es sich, sich schon früh mit den 864K auseinanderzusetzen.
Die 864K fordern sehr stark, hier spielen alle Spannungen mit hinein und AVX wird besonders stark angesprochen.
Listen Run 4800/4200/2400MHz:
3.2 Rockstable:
Das gezielte selektive Testen, ist die beste Methode sich den optimalen Werten zu nähern.
Wer glaubt er könne die Aussteiger gleich im Custom-Run richtig deuten, der irrt sich. Das ist viel schwieriger, das kann funktionieren, hat dann aber sicher viel mit Glück zu tun.
Zeitaufwendig ist es eh und letztlich nimmt es sich kaum etwas, ob nun mehrere Custom-Runs nach einiger Zeit aussteigen, oder man gezielt alle wichtigen Tests selektiv laufen lies.
Nach meiner Erfahrung hält ein für die Liste stabiler Run oft auch länger durch, es sei denn die Vcore ist wirklich noch am unteren Minimum, dann schafft man eventuell gerade die 1.5h.
Der Run kann auch länger durchhalten, bis zu 3h oder länger, aber dann kommen unwiderruflich Aussteiger, ohne erneut mehr Vcore geben zu müssen.
Jede Vcore Erhöhung kann dafür sorgen, dass es länger läuft, aber selbst nach 10h und mehr kann es erneut zu Fehlern kommen.
3.3 Der Full Custom-Run
Diese Ausführungen stammen aus den Anfangszeiten dieser Plattform, wo man noch ausschließlich mit der Version 27.9 testete.
Mit den neueren Bios/ME-Updates ist es auch nicht mehr so sensible, wie es damals zum Haswell Release war, wo Spannungen aufs mV stimmen mussten.
Ich denke, damit haben sich solche langen Prime-Run erledigt. Mit der Version 29.4 hat man bereits nach ~ 4,5-5h alle FFT-Tests durchlaufen, wo man mit 27.9 noch ~21h benötigte.
Man kann leider nicht vorhersehen, wie viel mehr Vcore nötig ist, damit es klappt und das System auch sonst in allem Szenarien stabil bleibt.
Leider kann man nicht einfach z.B. 20mV auf den Listen stabilen Wert geben, um sicher zu sein, dass es für den Full Custom Run reicht.
Hier kann eine erneute Vcore-Erhöhung zwischen 15-40mV über den Listen stabilen Werten nötigt sein.
Einfach nur die Vcore erhöhen muss nicht immer funktionieren. Die Eingangsspannung muss evtl. auch noch nach korrigiert werden.
Deshalb sollte man bevor man sich an den Full Custom Run wagt, 864K einzeln länger testen, bis zu 1.5h ist nötig, um sicher zu gehen.
Dazu sollte man aber vorher zumindest einen Listen-Run als Basis geschafft haben.
Falls die Vcore oder Vrin noch nicht reicht, bekommt man beim selektiven testen von 864K entweder Freezes, Kernausteiger oder reboots, was auch nach 45min und über einer Stunde auftreten kann.
Hier ist dann auch wieder Gefühl angesagt, um zu erkennen, ob es an der Vcore oder der Eingangsspannung liegt.
Die Vrin muss genau stimmen. Die Eingangsspannung kann für einen Full Custom Run höher sein, als für einen Listen-Run nötigt ist.
Eine zu hohe Input kann auch wieder reboots erzeugen, meistens aber eher xxx101er BSODs.
Bevor man einen solchen langen Run-Versuch startet, ist es eventuell von Vorteil unnötige Prozesse abzuschalten, um zu verhindern, dass solche den Run eventuell versauen.
Die Energiespar-Einstellungen sollte man im Windows auch so einstellen, dass das OS nicht in den Ruhemodus fährt und den Run verfälscht.
Ab wann Jemand sein System für ausreichend stabil ansieht, ist letztlich jedem seine Entscheidung.
Die Meinungen gehen halt oft auseinander, bezüglich was nötig ist, um von Rock-Stable sprechen zu können.
Es ist auch o.k. wenn jemand berichtet, dass er 5mV über seinem Listen-Run Setting alles machen kann, ohne Abstürze.
Diesbezüglich hat der gute Ralle_h sehr viele Spiele getestet und auch länger am Stück gespielt.
Damit auch wirklich alle Spiele laufen, war nach seiner Aussage der Full-Custom Run nötig.
Nur ca. 50-60% der Spiele liefen mit den 1344k Settings durch, der Rest brauchte den Full Custom.
Hierbei geht es nicht um Rivalität, sondern um Stabilität!
Genauer beurteilen können das nur User, die intensiv mehrere Stunden einige Titel zocken.
Die Aussteiger treten oft erst nach einigen Stunden spielen am Stück auf.
Listen Run vs. Full Custom Run
3.4 Full Custom Run Liste:
Bitte in dieser Form posten!
- 4670K|4500MHz|1,152V|45|100.0|3800MHz|2133MHz|Z87 ASRock Extreme6|Lukü|Geköpft|L311B215|Boxed|Ralle_h
- 4670k|4700MHz|1,205V|47|100.0|4000MHz|2400MHz|Z87M OC Formula|WaKü|Geköpft|L313B427|Boxed|Wernersen
- 4670k|4500MHz|1,193V|45|100.0|4000MHz|2000MHz|Asus Z87-PRO|LuKü|Geköpft|L315B334|Boxed|Kai85
- 4670k|4000MHz|1,065V|40|100.0|3800MHz|1600MHz|Asus Z87I-PRO|Lukü|Ungeköpft|L306C056|Boxed|chemieopfer
- 4770k|4700MHz|1,263V|47|100.0|4000MHz|2400MHz|MSI Z87-GD65 GAMING|Wakü|Geköpft|L310B491|Tray Herm
- 4770k|4700MHz|1,259V|47|100.0|4000MHz|2400MHz|Z87 OC Formula|Wakü|Geköpft|L310B491|Tray Herm
- 4790K|4500MHz|1,230V|45|100.0|4200MHz|2666MHz|Z97 ASRock OCF|Lukü|Ungeköpft|L331C517|Boxed|aerotracks
- 4790K|4400MHz|1,153V|44|100.0|4000MHz|2133MHz|Z97 ASRock Extreme4|Wakü|Ungeköpft|L336D106|Boxed|Flayer
- G3258|5000MHz|1,454V|50|100.0|4000MHz|2933MHz|Z87 Gigabyte OC|WaKü|Geköpft|3419B307|Boxed|brutus999
- 4790K|4700MHz|1,252V|47|100.0|4000MHz|2000MHz|Z87 ASRock OC Formula|LuKü|Geköpft|L420B750|Boxed|Kai85
- 4790k|4500MHz|1,204V|45|100.0|4200MHz|1866MHz|ASUS Z97-Pro|LuKü|geköpft|L422B688|Boxed|LuxSkywalker
- 4790k|4700MHz|1,327V|47|100.0|4000MHz|2666MHz|ASUS Z97 Hero VII|WaKü|geköpft|L423B529|Boxed|kasper96
- 4690K|4500MHz|1,113V|45|100.0|3900MHz|2666MHz|Z97 Asrock Fatal1ty Professional|WaKü|Geköpft|L315B334|Boxed|brutus999
- 4770K|4200Mhz|1,277V|42|100.0|3900Mhz|2400Mhz|Z87 Gigabyte G1.Sniper 5|WaKü|Geköpft|[Unbekannt]|Boxed|StarGeneral
- 4790K|4500MHz|1,186V|45|100.0|4000MHz|2400MHz|Asus Maximus VII Hero|Lukü|ungeköpft|L436C616|Boxed|Knolle100
- 4690k|4500MHz|1,249V|45|100.0|3900MHz|1866MHz|Asus Ranger Z97|H100i|Ungeköpft|L421C056|Boxed|m0nsta
- 4690k|4500MHz|1,235V|45|100.0|4000MHz|1333MHz|Z97X Gigabyte SOC Force|Wakü|ungeköpft|L426C075|Boxed|Darth Maul
- 4770k|4500MHz|1,160V|45|100.0|4300MHz|2400MHz|Z87 OC Formula|Wakü|Geköpft|L310B491|Tray Herm
- 4790K|4700MHz|1,273V|47|100.0|4400MHz|2600MHz|Z97 ASRock OC Formula|Wakü(AiO)|Geköpft|X441A903|Boxed|Digg
- 4690k|4000Mhz|1,086V|40|100.1|4000Mhz|1866Mhz|Asus Z97-M Plus|Wakü|Ungeköpft|L426C062|Boxed|OC-System
- 4670k|4500MHz|1,229V|45|100.1|3900MHz|2400MHz|Z87 ASRock Extreme4|Lukü|Geköpft|L350B801|Boxed|Coolsys
- 4790K|4800MHz|1,265V|48|100.0|4000MHz|2400MHz|Z97 ASRock Extreme9|AiO-Wakü|Geköpft|X437B337|Boxed|DaTraS
- 4790K|4700MHz|1,295V|47|100.0|4300MHz|2133MHz|Z97 Asrock Extreme4|Wakü 25C|Geköpft|L418C304|Boxed|envoy
- 4790K|4500MHz|1,170V|45|100.0|4000MHz|2400MHz|Gigabyte Z97X-SOC Force|Wakü|Geköpft|X441A704|Boxed|KampfGurke64
- 4790K|4700MHz|1,186V|47|100.0|4400MHz|2600MHz|Z97 ASRock OCF|Wakü|Geköpft|L420B759|Boxed|aerotracks
- 4790k|4400Mhz|1,148V|44|100.0|4000Mhz|2133Mhz|Z97 ASRock Extreme 4|Luft|Ungeköpft|L442B178|Boxed|Cabel
- 4690k|4400MHz|1,236V|44|100.0|4000MHz|1600MHz|Gigabyte Z97X-SOC Force|Luft|ungeköpft|L426C415|Boxed|Darth Maul
- 4690k|4500Mhz|1,272V|45|100.0|4000Mhz|2133Mhz|MSI Z97 Gaming5|Luft|geköpft|X516A793|Boxed|ragman1976
- 4770k|4500Mhz|1,261V|45|100.0|4200Mhz|1866MHz|ASRock Z87 Extreme4|Luft|Geköpft|L316B317|Boxed|steve2911
- 4790k|4600Mhz|1,256V|45|100.0|4000Mhz|2400MHz|MSI Gaming 5|Luft|ungeköpft|X511A809|Boxed|ragman1976
4.0 Bei Haswell sollte man nach dem Schwellenwert der Vcore schauen.
Damit ist gemeint, dass man zwar die Vcore in 1mV Schritten einstellen kann, aber nur 5mV Schritte einen Effekt in CPU-Z bringen.
Man kann z.B. im Bios 1.200 Vcore einstellen, aber in CPU-Z wird 1.198 an gezeigt.
Jetzt kann man schauen, wie weit man die Vcore in 1mV Schritten erhöhen kann, damit immer noch 1.198V angezeigt wird.
Falls das z.b. bei eingestellten 1.202 immer noch der Fall ist, wählt man natürlich den höhst möglichen Wert.
4.1 Eigenarten:
Die CPUen haben alle ihre Eingenarten. Bei einem 4770K L315B379 reicht die minimal nötige Vcore um 30min durch 1344K zu kommen, auch für einen mehrstündigen Custom-Run.
Dieser 4770K stieg mir dann allerdings zuerst im Custom-Run in 8K aus, hier war der Schlüssel die Cache 2mV zu erhöhen, dann liefen auch die 8K im Custom. So was findet man dann heraus, wenn man nach anderen Ursachen sucht und nicht gleich die Vcore anhebt.
Bei einem 4770K L311B492 war die 18K die Hürde und dann nur mit mehr Vcore dazu zu bewegen, durch den Custom-Run zu kommen.
Bei dem i5 4670K L313B427 habe ich beobachtet, dass man zwar die Vcore mit 1344K 1.5h abgesteckt haben kann, aber im Custom-Run kommt man nicht durch die kleinen K-Werte 8-12-18K.
Hier half letztlich nur die Vcore um 10mV zu erhöhen, um dann auch die 18K im Custom-Run zu meistern. Ein späterer Freez in 864K war der Anlass hier noch mal genauer zu schauen, an was es liegt.
Leider war erneut mehr Vcore nötig um die Probleme mit 864K zu beseitigen. Erst dann war ein mehrstündiger Custom-Run mit dem i5 4670K möglich.
Meistens sind späte Aussteiger im Custom-Run nur mit mehr Vcore in den Griff zu bekommen, egal ob die Aussteiger in kleinen oder in großen K-werten auftreten.
Wer also in höheren K-Werten jenseits der 768K Aussteiger im Custom hat, bekommt das höchstwahrscheinlich nur mit mehr Vcore in den Griff.
Wer mit solchen späten Aussteigern im Custom-Run kämpft, sollte wissen, dass ein zu hoher Uncore-Takt kontraproduktiv sein kann und man das nicht mehr mit den selektiven Tests, die eigentlich am stärksten auf die Cache wirken herausfinden kann.
Ich teste wirklich sehr akribisch und alle anderen Versuche waren ohne Erfolg.
Deshalb teste ich nach dem selektiven Testen anschließend noch 864K, bei der alle Komponenten hineinspielen.
4.2 BSODs und Symptome:
Hierzu gibt es leider keine allgemein gültigen Aussagen, man muss etwas Spürsinn und Intuition entwickeln.
Bei Haswell bekommt man zum größten Teil xxx124 BSODs, bis man sich mit der Vcore-Input und Cache an die richtigen Werte genähert hat.
Bei Neustarts ohne BSODs und Fehlermeldung stimmt zu 100% die Eingangsspannung noch nicht bzw. ist diese meisten zu niedrig, es kann aber auch bei zu geringer Vcore zu reboots kommen.
Bei xxx101er BSODs stimmt oft Eingangsspannung/Vrin meistens noch nicht, oder es liegt am Verhältnis Vrin/ LLC-Level.
Freezes liegen meist an einer zu niedrigen Vcore oder Vdimm.
Sehr schnelle Aussteiger mehrer Kerne mit rounding errors sind immer auf die Agent zurückzuführen, es ist aber zu bedenken, dass die VTT dort mit hineinspielt.
Ein später Aussteiger im Custom-Run, auch nur mit rounding error auf einem Kern, liegt meistens an der Vcore.
Einzelne Kernaussteiger mit rounding errors können auch an der Vdimm liegen, welches man aber erst feststellen kann, wenn man bereits eine stabile Basis geschaffen hat.
Bei Rounding-Errors die nach einer gewissen Zeit ziemlich gleichzeitig auftreten, liegen eher an der Vdimm.
Rundungs-Fehler mit Dezimalzahl im Code liegen eher an der SA/VTT Kombi.
Falls sich der Prime95 Prozess schließt, ist die System Agent zu hoch.
WHEA Logger in der Windows Ereignisanzeige liegen an zu wenig Vcore. Eine zu geringe Input ergibt reboots, nur können diese auch sehr spät auftreten, nach einigen Stunden.
Eine zu hohe Input kann auch reboots erzeugen, oft aber auch xxx101er BSODs.
Bei einigen Chips kassiert man ab gewissen Regionen Temperatur-bedingt xxx101er BSODs. Hier hilft nur besser kühlen.
Intel hat uns hier eine wirklich schwierige Chip-Generation serviert.
Man muss echte Detektiv-Arbeit leisten um herauszufinden, was bei seinem System nötigt ist.
* 0x124 = VCore
* 0x101 = Input (~ 90 Prozent) oder VCore (~ 10 Prozent)
* 0x1E = VCore
* 0x3B = VCore
* 0x50 = RAM/Cache
* 0x9C = Cache oder System Agent
* 0X109 = Cache/VDimm
* 0x0A = VTT/Sys Agent
Wichtig ist es zu bedenken, dass Voltages wie die System Agent und VTT=I/O Offset in einer Wechselwirkung zueinander stehen.
Ich konnte auch beobachten, dass die Vcore und die VRing/Cach-Voltage ebenfalls in gewisser weise eine Wechselwirkung zueinander aufweisen, bzw. ein hoher Uncore-Takt erst mit genügend Vcore machbar wird. Mit zu knapper Vcore (1.5h Listen Run), ist bei manchen Chips ein hoher Uncore-Takt auch nicht mit mehr VRing=Cache-Voltage durch längere Run's zu bewegen. 4 oder 4.2GHz Uncore stellten keine Hürde dar, schwierig war es die 4.5GHz Uncore-Takt durch längere Runs zu bekommen.
Dieses Verhalten rechtfertigt längere Custom Runs. Erst das Full-Custom Setting als Basis, hat mich tiefer blicken lassen.
Sehr wichtig!
Eine Eigenart dieser Plattform ist, dass man fast bei jeder Veränderung im Bios, gerade an der Eingangspannung und Cache-Voltage, einen obligatorischen Blue-Screen in Prime95 kassiert. Diese Sensibilität liegt sicher daran, dass die Steuerung der Spannungsversorgung in die Chips gewandert ist.
Hiervon darf man sich nicht gleich verwirren lassen und nicht sofort eine Einstellung ändern, sondern einfach erneut starten und mit gleichen Einstellung noch mal versuchen.
Dieser Blaue kommt dann recht schnell innerhalb der ersten Minuten, trotzdem die Veränderung schon richtig gewesen sein kann und führt deshalb oft zu Verwirrung.
Am besten man schaltet den PC nach jeder Änderung einmal aus. Kostet zwar etwas Zeit, spart aber langfristig echt Nerven, da man sich so die ganzen "random" iVR Bluescreens sparen kann.
Eine altbewährte Regel beim Overclocken ist, nicht gleich mehrere Veränderungen auf einmal vornehmen, sondern immer nur eine und schauen was passiert.
Notizen helfen sehr den Überblick zu behalten.
Auch erfahrene Overclocker nutzen zwar die Profile im Bios, aber es geht nichts über ordentliche Notizen.
Es kann vorkommen, dass die Profile im Bios plötzlich nicht mehr vorhanden sind.
Im Fall der Fälle hat man immer noch seine Notizen.
Es gibt auch die Funktion seine Bios-Einstellungen/Profile und Screens zu speichern.
Die Bios-Einstellungen und Profile können aber nur in die jeweilig passende Bios-Version zurück gespielt werden.
Absolut notwendig!
Beim Overclocking sollte man sich über jede Spannung im klaren sein und wie viel hier unbedenklich ist.
Wer mit den ganzen Begriffen noch nicht so sicher ist, sollte sich generell Notizen machen.
Falls man hier VRin und VRing verwechselt könnte fatale Folgen haben.
Ich möchte nicht, dass jemand seine Hardware beschädigt!
Natürlich lebt eine Community vom miteinander.
Dies ist eine Zusammenfassung meiner Erfahrungen und dem Wissen, welches ich bis zu diesem Zeitpunkt sammeln konnte.
Ich nutze auch das Wissen anderer User, welches hier und in anderen Foren veröffentlicht wurde/wird.
Dank an alle Luxxer, die immer sehr gute Tipps geben.
Disclaimer: Overclocking geschieht auf eigene Gefahr!
Kein Anspruch auf komplette Richtigkeit, keine Haftung seitens des Erstellers dieses Threads oder des HardwareLuxx Forum.
Autor: Wernersen
Ich wünsche viel Spaß und Erfolg beim Testen eurer Haswell-CPU/CPUen.
Zuletzt bearbeitet:
danke für jede Hilfe !
