[Sammelthread] -= OC Prozessoren Intel Sockel 1155 (Ivy Bridge) Laberthread =-

Ah stimmt, das ist dieser unsägliche UEFI LLC Bug bei Gigabyte und fixed VCore - hatte ich ganz vergessen.

Da bleiben dir nur 2 bzw. 3 Möglichkeiten:
- Multi senken
- Doch mit dem Offset Modus arbeiten (vllt. ist das Problem mit Dual Channel ja nun weg)
- Eine ältere UEFI Version probieren, die diesen Bug noch nicht hatte
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
is mir damals beim UD3H gar nicht aufgefallen oder der Bug ist nicht bei allen so...

ah ok ist nur bei fester vcore so

ralle wieder schneller :fresse:
 
Da bleiben dir nur 2 bzw. 3 Möglichkeiten:
- Multi senken
- Doch mit dem Offset Modus arbeiten (vllt. ist das Problem mit Dual Channel ja nun weg)
- Eine ältere UEFI Version probieren, die diesen Bug noch nicht hatte

Möglichkeit 1) Jo, ob ich mit 43 oder 44 fahre dürfte letztendlich total egal sein. Mir stellt sich eher die Frage - ist das schädlich? Laut deinem Guide ja, aber ich bin ja noch in eher niedrigen Spannungsregionen. Wenn bei 1.188 V eine Spannungsspitze kommt dann wird da ja nicht sonderlich mehr anrichten als eine bei 1.176 V (normaler VDrop). Oder irre ich mich da?
Möglichkeit 2) Kann ich morgen mal testen... ich hab da aber eher wenig Hoffnung...
Möglichkeit 3) Wäre ein bisschen blöd, da hab ich heute das allerneuste BIOS von J Z draufgemacht und dann soll's wieder dem ältesten Kram überhaupt weichen. Gibt's überhaupt BIOSe ohne diesen Bug? Im Gigabyte Thread wurde ja schon das F14 in Zusammenhang mit dem Phänomen benannt. Zudem hab ich ein Rev 1.1 Board - ka ob man da ältere BIOSe drauf machen kann, es kam mit dem F15. Wenn der Bug schon solange bekannt ist - warum hat Gigabyte oder J Z den dann noch nicht gefixed?

---------- Post added at 02:55 ---------- Previous post was at 02:37 ----------

Okkkkaaaaayyyyy...

Jetzt _musste_ ich CMOS resetten. Ob ich wollte, oder nicht. PC fror beim Booten vor oder während dem BIOS ein. o.o

Hintergrund:

Prime kackte gerade doch nach einer Stunde ab. Von daher dachte ich mir, dass ich auch noch mal wie vorgeschlagen den Offset-Mode testen könnte. Gesagt getan -> Nö, immer noch dasselbe Problem. Also wollte ich mit fixer VCore weitermachen. Also dieses Mal statt 1.085 V 1.090 V. Gesagt, getan, eingestellt, Reboot... Peng, Neustart während er Windows lädt. Und danach... Freeze sobald ich im BIOS war.
 
Mir stellt sich eher die Frage - ist das schädlich? Laut deinem Guide ja, aber ich bin ja noch in eher niedrigen Spannungsregionen. Wenn bei 1.188 V eine Spannungsspitze kommt dann wird da ja nicht sonderlich mehr anrichten als eine bei 1.176 V (normaler VDrop). Oder irre ich mich da?

Die Spannungsspitzen würden dann ca. bis 1,288V gehen - aber das lässt sich nur schätzen.

Schädlich wäre das in den Regionen noch nicht (die Höhe Spannungsspitze), aber es ist eher eine grundsätzliche Frage (zumindest für mich):
- Wieso überhaupt mit höheren Spannungsspitzen leben, als nötig?
- Wieso nicht die Loadline nutzen, die Intel für die CPUs vorsieht? Vdrop und Vdroop haben ja einen Sinn (siehe P.S.)
- Wenn schon LLC so fehlerhaft implementiert ist, dass die Loadline rum zickt bzw. nicht das macht was sie sollte, wer weiß schon wo es dann noch klemmen könnte bzw. ob nicht doch irgendwie was schädliches passieren kann?

Gibt's überhaupt BIOSe ohne diesen Bug? Im Gigabyte Thread wurde ja schon das F14 in Zusammenhang mit dem Phänomen benannt. Zudem hab ich ein Rev 1.1 Board - ka ob man da ältere BIOSe drauf machen kann, es kam mit dem F15. Wenn der Bug schon solange bekannt ist - warum hat Gigabyte oder J Z den dann noch nicht gefixed?

Jep, der Bug kam erst mit den neuen UEFI Versionen irgendwann dazu. Ab welcher kann ich dir leider nicht sagen, da ich das Geschehen rund ums D3H nicht so verfolge.


P.S: Zu Vdrop und Vdroop:
Ganz simple Analogie, die ich aus einer guten und tiefsinnigen Diskussion in einem alten Forum(-Archiv) über LLC aufgeschnappt habe:
Stell dir vor du müsstest ein schweres Gewicht fangen (=Lastenwechsel der CPU). Normalerweise geht der Mensch dabei in die Knie um den Fang abzufedern. Genau das machen Vdrop und Vdroop, sie federn die Spannungsspitzen beim Lastenwechsel ab. Stell dir nun vor man verbietet dir in die Knie zu gehen... das geht sicher eine Weile gut, aber auf Dauer dann doch sehr aufs Kreuz. Die berechtigte Frage ist: Wieso sollte man also nicht in die Knie gehen, um die Wucht abzufedern? Nur weil es kosmetisch besser (in unserer Analogie vllt. "stärker") aussieht? :d

Damit will ich nicht sagen dass LLC gar keinen Nutzen hat. Den hat es im Extreme OC und bei hohen Multis schon, aber in diesem Bereich sicher nicht. Vor allem nicht wenn die Loadline noch verbuggt implementiert wurde ^^
 
Zuletzt bearbeitet:
Mkay...

Also, ich hab's jetzt nach dem CMOS-Reset noch mal mit dem Offset probiert. Scheint jetzt zu gehen. Allerdings ging's gestern ja auch ne Zeitlang. Ich hab jedoch heute (im Gegensatz zu gestern) ne Offset von +0.010 V (gestern hatte ich ja die ganze LLC noch auf Turbo). Vielleicht hilft das ja schon. Damit lande ich unter Last bei 1.128 V, also genau demselben Wert, bei dem vorhin (mit fester VCore) Prime nach ner Stunde verreckte.
Von daher denk ich werd ich jetzt noch 5 mV draufhauen, Prime anschmeißen, in's Bettchen gehen und hoffen, dass es morgen früh auch noch läuft. ^^

Und vor allem, dass der Offset dieses Mal nicht rumzickt... auf jeden Fall vielen Dank für die Erklärungen. :)

---------- Post added at 03:20 ---------- Previous post was at 03:13 ----------

Nachtrag:

Der Offset will aber irgendwie immer noch nicht...

+ 0 mV Offset ergibt 1.104 V unter Last
+ 10 mV Offset ergibt 1.128 V unter Last
+ 20 mV Offset ergibt 1.128 V unter Last

Irgendwas stimmt hier doch nicht...
 
Du musst bedenken dass CPU-Z bei Gigabyte Boards nur in 0,012V Sprüngen reagiert. Das kann durchaus schon mal +15mV brauchen, bis sich die Anzeige in CPU-Z ändert.
 
Ah, okay. Das wusste ich nicht. Allerdings seh ich mit dem Offset Mode derzeit auch keinen VDrop und wenn dann nur einen kleinen VDroop. Die maximale Spannung, die HWInfo64 feststellt, ist nur 12 mV oberhalb von der Lastspannung.

Zudem passen die Werte auch nicht. Im BIOS steht bei VCore was von 1.080 V, da hab ich derzeit einen Offset von 15 mV drauf. Wie man dann bei 1.128 V unter Last landet ist mir erst mal schleierhaft.
 
Zuletzt bearbeitet:
Guck mal hier zu Vdrop + Vdroop bei Offset:

#8838
 
Ich glaub jetzt hat's Klick gemacht. Ein Mischmasch aus deinem Link und deinem Guide. :)

Die Spannung im DVID Mode wird allerdings eben nicht mehr absolut eingestellt, sondern als Differenz zur VID des jeweiligen Multiplikators - meist in +- 0,005V Stufen (je nach BIOS und Mainboard).

D.h. diese 1.080 V im BIOS bei VCore interessieren mich gar nicht mehr - das wo ich den Offset draufhaue ist die VID?!

Die VID schwankt bei mir allerdings auch... je nach Last zwischen unter 1 V und maximal 1.1709 V.

Beispiel:

Wenn ich derzeit einen großen Prime Test laufen lasse (z.B. 864K) dann ist die VID bei 1.709 und VCore bei 1.140 Bei einem kleinen Test (12K) ist die VID bei 1.1659 und VCore bei 1.128. Das ist normal?

Und VDroop und VDrop ist dann immer noch vorhanden, wird nur halt jetzt auf die VID angewendet...? Und die VID, die ich in Core Temp sehe ist schon die nach dem VDrop? Und VCore ist dann das, was nach VDroop übrig bleibt?

Also letztendlich seh ich beim Übertakten per Offset im BIOS nicht, worauf ich jetzt meinen Offset draufsetze, weil ich dort die VID nicht sehe?
 
Zuletzt bearbeitet:
Ist bei euch eigentlich schon einmal Prime95 abgestürzt? Also kein System Crash, kein Kern der aussteigt, einfach nach 6,5 Stunden: "Prime95 wurde beendet."

WHEA Fehler gibt es in der Zeit keine.

Hier die Fehlermeldung:

Name der fehlerhaften Anwendung: prime95.exe, Version: 27.6.1.0, Zeitstempel: 0x4fa076ea
Name des fehlerhaften Moduls: prime95.exe, Version: 27.6.1.0, Zeitstempel: 0x4fa076ea
Ausnahmecode: 0xc0000005
Fehleroffset: 0x00000000001720af
ID des fehlerhaften Prozesses: 0x6dc
Startzeit der fehlerhaften Anwendung: 0x01ce058ca7259f3a
Pfad der fehlerhaften Anwendung: C:\Users\\Documents\Benchmark Programme\p64v276\prime95.exe
Pfad des fehlerhaften Moduls: C:\Users\\Documents\Benchmark Programme\p64v276\prime95.exe
Berichtskennung: 3af5dbaa-71b7-11e2-beef-c860009b6318
Vollständiger Name des fehlerhaften Pakets:
Anwendungs-ID, die relativ zum fehlerhaften Paket ist:
 
Ja, ist mir auch passiert. Eine stufe mehr vcore hat für abhilfe gesorgt ;)
 
japp ist auch ne Form der Instabilität :)
 
Japp, genau das ist gerade mein Problem...

Offset 10 mV ---> Crash nach ca ner halben Stunde
Offset 15 mV ---> Crash nach ca ner halben Stunde
Offset 20 mV ---> Crash nach ca ner Stunde
...
Offset 40 mV ---> Bis jetzt (~4h) stabil...

Aber alles andere lief perfekt. Nur Prime stresst. Und lustigerweise hatte ich diese Instabilitäten VOR meinem Switch auf Dual Channel gar nicht. Da lief Prime mit Offset 0 mV durch. ^^

---------- Post added at 12:22 ---------- Previous post was at 12:20 ----------

Äh, und das was ich mir da oben zusammen fabuliert hab... stimmt das jetzt oder ist das Seemannsgarn?
 
deswegen ist ja Prime der Stresstest für OC ;) Und warum es jetzt instabil ist erklärt sich durch den IMC :)

die VID ist eine variable Größe :)
 
Hm... noch eine Frage zur VCore unter Last:

Ich lasse ja gerade Prime Custom durchlaufen... bei kleinen FFT-Längen (atm 100K) droppt die VCore auf 1.140 V runter. Bei großen FFT-Längen (z.B. 864K) droppt sie nur auf 1.152 V runter. Ist das normal?
 
Ja ist ganz normal, die Tests belasten die CPU unterschiedlich daher ergeben sich auch andere lastspannungen.
 
Ich glaub jetzt hat's Klick gemacht. Ein Mischmasch aus deinem Link und deinem Guide. :)

Die VID schwankt bei mir allerdings auch... je nach Last zwischen unter 1 V und maximal 1.1709 V.

Die VID ist, wie du schon festgestellt hast, dynamisch bzw. sogar doppelt dynamisch.
- Sie verändert sich je nach Multiplikator
- Sie verändert sich je nach Last

Ist aber kein Problem, da der Offset ja ein Offset ist und es somit kein Problem ist wenn sich die Basis verändert. Die Differenz/Skalierung bleibt ja immer gleich.

D.h. diese 1.080 V im BIOS bei VCore interessieren mich gar nicht mehr - das wo ich den Offset draufhaue ist die VID?!

Die 1,08V kannst du wirklich vergessen, was die Anzeige anzeigt bzw. anezeigen soll kann dir wohl niemand außer Gigabyte verraten. Die VID des Standard Multis? Die Vorgeschlagene VCore für den Standard Multi ("Standard VCore")? Die VID für x44 oder x45 ist es aber definitiv nicht!

Wie der anliegende Offset die Spannung beeinflusst, und was am Ende dabei rauskommt, korrekt per Hand zu berechnen ist echt sehr schwer bis unmöglich, hier gilt wirklich "Probieren geht über Studieren".

Wenn, dann in ist es in etwa so zu berechnen: ((VID des anliegendes Multis) + Offset) - (Vdroop + Vdroop).

Ich weiß aber nicht ob der Vdrop und Vdroop auf den Wert mit oder ohne Offset kommt, dann müsste man ggf. die Klammern anders setzen.

P.S: Habe mich geirrt. Den LLC Bug wirst du auch mit alten UEFI Versionen haben, daher brauchst du das gar nicht probieren.
 
Zuletzt bearbeitet:
Japp, genau das ist gerade mein Problem...

Offset 10 mV ---> Crash nach ca ner halben Stunde
Offset 15 mV ---> Crash nach ca ner halben Stunde
Offset 20 mV ---> Crash nach ca ner Stunde
...
Offset 40 mV ---> Bis jetzt (~4h) stabil...

Aber alles andere lief perfekt. Nur Prime stresst. Und lustigerweise hatte ich diese Instabilitäten VOR meinem Switch auf Dual Channel gar nicht. Da lief Prime mit Offset 0 mV durch. ^^

---------- Post added at 12:22 ---------- Previous post was at 12:20 ----------

Äh, und das was ich mir da oben zusammen fabuliert hab... stimmt das jetzt oder ist das Seemannsgarn?

Wie switche ich auf Dual Channel?

Gesendet von meinem GT-I9300 mit der Hardwareluxx App
 
@erwingage

Du steckst den RAM um. Sofern du ihn, wie ich Trottel, in die falschen Slots gesteckt hast. :p

@ralle:

Kay, thx. Dann ergibt das ja schon mal fast alles Sinn. Bis auf die Sache mit den komischen Boot Crashs beim Offset und der dann im BIOS stehenden 0.995 V bei VCore. Eigentlich sollte die dann ja nichts damit zu tun haben, aber effektiv wird da wohl doch ein Zusammenhang bestehen...
Ich hoffe mal, dass das jetzt nach dem CMOS Reset, dem RAM Umstecken und den + 40 mV Offset nicht mehr passiert. Wenn doch... weiß ich auch nicht weiter. :fresse:

Ich hab jetzt seit heute morgen 7 Uhr meinen Custom Run mit Offset + 40 mV laufen. So langsam glaub ich, dass das jetzt wirklich stabil ist. :fresse:
Maximaltemperatur waren laut Core Temp 73°.
Wie lange sollte ich das Ding denn jetzt noch laufen lassen um auf Nummer sicher zu gehen? ^^
Für die OC-Liste ist der Run eh nicht zu gebrauchen weil's Prime 27.7 und nicht 26.6 ist.

Und noch eine Frage zur zappelnden VCore unter Last: Welche geb ich denn dann an (für das "4400 Mhz @ x.y V")? Die niedrigste unter Last? Wären bei mir 1.140 V. :)
 
CPU-Z auf, Reiter Memory:

Bei Channels# steht dann entweder Single oder Dual.

Den genauen technischen Hintergrund kenne ich nicht, aber afaik werden bei zwei RAM-Riegeln im Single Modus die Module nacheinander beschrieben/abgefragt, während sie beim Dual Channel gleichzeitig bearbeitet werden.
Wenn dein Board also vier RAM-Bänke hat, von denen zwei mit Channel A und zwei mit Channel B angesprochen werden, dann müsstest du für Dual Channel je einen Riegel in eine von Channel A und eine von Channel B bediente Bank schieben. Meistens gibt's da genaue Konstellationen, die du einhalten musst. Das findet sich dann alles im Mainboard Manual.
 
Leute. Eure CPU übertakten wollen aber nicht mal wissen wie man seinen RAM richtig einbaut.
Bitte, informiert euch über das was ihr tut. Und zwar richtig! Das spart Zeit, Nerven und vor allem auch Geld.
 
~.~

Den Spruch kannst du dir sonst wohin stecken. Als ich meinen PC zusammengebaut hab, wollte ich natürlich schon auf Dual Channel achten. Normalerweise sind die RAM-Bänke ja farbig markiert. Aber beim D3H sind sie alle in einem schönen, einheitlichen Schwarz. Gut, was macht man dann? Zwei Möglichkeiten, entweder man schaut in's Manual oder man bemüht google. Ich hab letzteres getan und bekam diesen Thread hier als Ergebnis.
Da sind DREI Leute, die sich ALLE auf's Manual beziehen, und JEDER sagt dasselbe - 1 und 3 bzw. 2 und 4. Es ist allerdings genau umgekehrt. Woher hätte ich das denn wissen sollen, dass hier gleich drei Mal hintereinander Blödsinn steht?
 
~.~

Den Spruch kannst du dir sonst wohin stecken. Als ich meinen PC zusammengebaut hab, wollte ich natürlich schon auf Dual Channel achten. Normalerweise sind die RAM-Bänke ja farbig markiert. Aber beim D3H sind sie alle in einem schönen, einheitlichen Schwarz. Gut, was macht man dann? Zwei Möglichkeiten, entweder man schaut in's Manual oder man bemüht google. Ich hab letzteres getan und bekam diesen Thread hier als Ergebnis.
Da sind DREI Leute, die sich ALLE auf's Manual beziehen, und JEDER sagt dasselbe - 1 und 3 bzw. 2 und 4. Es ist allerdings genau umgekehrt. Woher hätte ich das denn wissen sollen, dass hier gleich drei Mal hintereinander Blödsinn steht?

Bei meinem z77 D3H sind die Ram Bänke blau/weiss farbig.
Im Hnadbuch steht für optimale Performance sollen die Riegel in sockel1 und sockel2.
 
Ich hab aber das Z77X-D3H. Da ist alles schwarz. ;)

Und jo, Sockel 1 und 2. Da die RAM-Bänke aber so angeordnet sind: 1,3,2,4 musst du die Riegel in den ersten und dritten Slot stecken.
 
~.~

Den Spruch kannst du dir sonst wohin stecken. Es ist allerdings genau umgekehrt. Woher hätte ich das denn wissen sollen, dass hier gleich drei Mal hintereinander Blödsinn steht?

wir bleiben alle entspannt ;)

der direkte Blick ins Handbuch hätte durchaus geholfen. Zum Teil irritieren die Farben auch einfach. Manchmal sind es die gleichfarbigen Slot .... manchmal müssen aber die Unterschiedlichen genutzt werden... ist nicht nur vom Hersteller abhängig sondern teilweise auch innerhalb der Herstellerboards unterschiedlich
 
Na wenn hier sowieso nur Blödsinn steht dann brauchst du hier auch nicht nachfragen.
Es gibt nunmal ein gewisses Grundwissen. Das sollte man meiner Meinung nach mitbringen wenn man sich schon an das Übertakten machen muss.

In euerm Job könnt ihr doch auch nicht weger jedem Furz nachfragen. Eigeninitiative sollte kein Fremdwort sein. So lernt man auch wesentlich schneller und effektiver anstatt wirklich immer nachzufragen.
Wie gesagt, dass ist meine Meinung. Und ich bin auch gerne der Buhmann. Hab ich kein Problem damit :)

Und meinen Spruch werde ich mir nirgends hinstecken.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh