Wie bekomme ich meinen PC stabil nach OCen? (Teil 2)

du lagst, unter "schnell" versteh ich net 12h delay :fresse: aber ram rannte nun 6h cpu-zeit inlarge durch. dürfte man als fsb-stable bezeichnen :bigok:
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
So... ich hab Prime relativ stabil bekommen, d.h. 10min laufen lassen dann sicherheitshalber wieder runtergetaktet..

PLL 1.5
NB 1.38
VTT 1.38
GTL 0,65

Das sind unmenschliche Spannungen oder? Und ein Problem hab ich auch - MB-Temperatur bleibt irgendwie nun immer auf 33 Grad - egal was ich tue.

Auch bei weniger MHz und weniger vNB... hab ich da was zerstört?
 
Das mit der MB-Temperatur hatte ich bei meinem alten Maximus Formula auch, da hat sich die MB-Temperatur garnicht oder max. 1° verändert. Denke nicht dass da was kaputt ist. Im GTL-Thread steht, man sollte die VTT für 24/7 nicht über 1,35V haben, am besten noch etwas weniger. PLL sollte man immer auf 1,50V halten! 1,38VNB ist zwar schon ein bisschen aber das halte ich nicht für gefährlich solange die Temperatur ok ist und die NB kann ja bis zu 90° ab, bis 70° sollte man also noch im grünen oder gelben Bereich sein.
 
Hi danke dir schonmal!

Also dass mein MB-Sensor nun steht ist natürlich doof...

... und zu den Werten hier mal zum Vergleich:

468: VNB 1,3 VTT 1,28

480: VNB 1.38 VTT 1,38

Das ist natürlich in keinem Verhältnis zu den dadurch entstehenden 100Mhz-Zuwachs oder?
 
Nicht wirklich. Würde ich so (480) wohl nur zum Benchen benutzen aber nicht 24/7.
Ich habe allerdings auch keine Erfahrung mit Quadcores, vieleicht guckst hier im Thread mal nach vergleichbaren Settings. 480 ist für einen Quad aber schon recht ordentlich soweit ich das bis jetzt in den Threads, in die ich reingucke, gesehen habe.
 
Hi!

Habe mal ne Frage bezüglich der MCHCore beim UD3R/D2Core E8400 und dem Test (Blend) beim primeln:

momentan primle ich bei 475x8 mit einer MCHCore von 1.22v

Absolut stabil!

Eine versuchsweise Erhöhung der MCHCore auf 1.24v brachte schon nach 6min im Blendtest einen Coreabbruch.Wie kann man dies erklären?
Ich meine, ne winzige Erhöhung und das System ist nicht mehr "stabil"!!!

Außerdem brauche ich eine Vcore von 1.3562v(im BIOS) um 3,8Ghz stabil zu primeln.Könnte man die Vcore noch eventuell absenken, wenn man die Gttls(MCH ref. und CPU ref.)versucht etwas zu senken(z.Z. bei 0,76 beide, da CPU Term. bei 1.20v ist und diese Refs autom. eingestellt werden!)?

Die Vorgehensweise wäre wohl folgende(bitte berichtigen wenn sich da ein Fehler eingeschlichen hat!):

Vcore absenken(1 Schritt)-dann Prime Small laufen lassen und schauen ob CPU stabil, wenn nicht, jetzt die CPU ref. etwas absenken und wieder testen.
Wenn keine verbesserung, dann zusätzl. MCH ref. absenken und wieder testen...

Ich hoffe, ihr könnt mir etwas dabei helfen!


MfG.
 
Wenn beim Large_Test bei 640k die beiden Kerne nach und nach aussteigen, liegt das an der Vcore oder eher an der MCHCore und/oder CPU term.?
 
hi leute ich habe ein problem mit mein pc,unter prime 95 10stunden und untel IBT 20durchleufe leuft er durch auch video konvertieren und games schaft er sauber ,aber gestern und heute ist err eingefroren nicht unter last sondern ganz im idle
ich hab hier 2 bilder gemacht vielleicht weist ihr was sie heissen

http://img134.imageshack.us/i/bluskreen1.jpg/

http://img268.imageshack.us/i/bluskreen2.jpg/

konnte das ein windows 7 rc fehler sein,sollte ich windows vista wider instaliren

danke leute
 
Zuletzt bearbeitet:
aha und wie konnte ich das rausfinden,soll ich die trebier runter hauen und wider instaliren oder ganz formatiren

danke
 
es kommt kein Bluescreens er friert nur ein das heißt ess geht nichts mehr,ein restart und es funksioniert super
das shtecht wenn ich den pc dann einschalte vielleicht ist das hilfreich

http://img134.imageshack.us/i/bluskreen1.jpg/


und die andere hälfte


http://img268.imageshack.us/i/bluskreen2.jpg/


EDIT- ich hab mich bisschen um gesehen und ich glaub der bluescreen haben auch ein paar leute,ich glaub er kommt von den vga treibern .... fileich hilft euch das weiter

danke :d
 
Zuletzt bearbeitet:
prime ist 10 stunden fehlerfrei gelaufen,ibt und linx hab ich auch getestet lief auch stabiel
also jetzt hab ich die neuen nvidia treiber installiert mal schauen wie es leuft
unter last läuft der pc super aber ich hatte 2 mal im idle freazes
 
In Einzelfällen liefern Testprogramme (nicht nur Prime) auch Fehler wo garkeine sind, das liegt dann am Algo vom Tool selbst.

Ich nehme mal an, Du hast den gesamten Prime-Lauf, in dem das vorkam, von Hand nachgerechnet, und Wert für Wert überprüft.

Oder in anderen Worten: Deine Aussage ist (wie vieles in diesem Thread) hanebüchener Unsinn. Nicht etwa mit an Sicherheit grenzender Wahrscheinlichkeit auszuschliessen, sondern so sicher wie die Annahme, daß die Erde eine Scheibe sein könnte.

Wenn Prime einen Plausibilitätsfehler meldet, ist auch ein Fehler in der Hardware aufgetreten. Hinnehmen, lernen, Danke sagen.

Anderes Thema: Freezes sind zu 99,9% durch halbgare Werte auf Steuerleitungen am Speicherbus bedingt. D. h. VDimm, VNB (oder eben bei manchen VMCH), in eher seltenen Fällen FSB-VTT / GTLs.

Noch ein Hinweis: es ist Jacke wie Hose, ob man GTLs in Prozent oder in mV wählt, weil sich die Werte aus kapazitativen und induktiven Effekten ergeben und keine feste Zuordnung zu FSB-VTT möglich ist. Andere FSB-VTT und anderer Takt und andere Einflüsse verändern Signalanstiege und Einstreuungen ohne festes Schema und die Einstellung, mit der man den Bus dagegen stabilisieren kann, muß man empirisch ermitteln. Das ist einer der wenigen Bereiche, der wirklich bei jedem individuell ausfällt. Die Umrechnerei kann man sich also getrost sparen.
 
Zuletzt bearbeitet:
ich bin grade am ocen eines E5200...aber ich bekomme nich mal 5min Blend stable! Die 20k laufen, also gehe ich davon aus das die vcore reicht!

Hat jemand tips für die E5200, bzw. muss ich da was beachten, im gegensatz zum e8400?
 
@coldblooded: Komisch, dass bei Kisten im Auslieferungszustand teilweise bei manchen Versionen Fehler kamen obwohl keine HW Defekte da waren :) Hinnehmen,... (oder wollen wir sachlich bleiben? :) )

zu der Umrechnerei. Dann hast du etwas missverstanden bzw ich mich falsch ausgedrückt, natürlich ist es egal ob es mV oder % oder sonstwas ist, allerdings benutzt Asus ein anderes Prinzip als die meisten anderen Hersteller (unterstreiche mir das net, sondern schau auf XS oder in Datenblättern nach). Ich rechne um, weil ich meine bisherigen Erfahrungswerte natürlich auch dort probieren will, in einem gewissen Bereich.

Das mit den Freezes ist Auslegungssache, wenn der DAU dransitzt und net weiß was Speicher und NB wollen, liegt es natürlich daran. Sobald das aber passt wovon man meistens ausgeht bist du gerade bei deinen 0,1% (woher kommt die Zahl, hast du bei 100 Leuten empririsch ermittelt?) Also nach meiner Erfahrung befinde ich mich fast ausschließlich in diesem kleinen Bereich, bzw. VDimm und VNb sind schnell ermittelt.
 
Zuletzt bearbeitet:
Dafür brauchts keine Defekte. Ungünstige Betriebszustände und/oder ungünstige Kombinationen von Toleranzen und verdeckten Einstellungen, die das BIOS vornimmt, können das schon auslösen.

Worum's mir geht, ist folgendes: Ich mache seit über 30 Jahren hardwarenahe Programmierung und kenne die Grundlagen wie kaum jemand sonst. Sporadisches Versagen von Plausibilitätschecks wie sie in Prime verwendet werden ist prinzipbedingt unmöglich.

Es kommt halt vor, daß Hardware-Kombinationen gerade mal so, also grenzwertig kompatibel ausgeliefert werden, z. B. wenn Speicher und Board nicht gut harmonieren. Dann ist auch ohne OC und ohne Defekte plausibel, daß unter grenzwertigen Betriebsbedingungen (Sommer, hohe Last) mal die Flankensteilheit auf dem Bus nicht mehr passt. Genausogut können HF-Einstreuungen durch Sendemasten oder Handys schon mal den Grund dafür liefern.

D. h. Prime stellt Fehler fest, die immer bedeuten, daß ein Wert im RAM oder im Cache tatsächlich durch temporäres Hardware-Versagen bedingt etwas anzeigt, das auf keinen Fall als Ergebnis der durchlaufenen Routine zustandegekommen sein kann. Das ist kein Fehler des Algorythmus. Solche Fehler würden zuhauf vorkommen und bei jedem so zuverlässig wie ein Uhrwerk und sie wären längst behoben.

Man sollte vielleicht formulieren: Von Prime angezeigte Fehler bedeuten immer, man hat nicht unter allen Umständen grenzenlose Stabilität (was auch immer man sich darunter vorstellt), sind aber nicht zwingend ein Grund, etwas zu ändern oder graue Haare zu bekommen. Es wär halt unpassend, wenn der Eindruck entstünde, Prime sei in der Hinsicht fehlerhaft programmiert, denn das ist es nicht.

Ich mein, mein Nachbar hat seinen PC nie länger an als zwo Stunden und der hat auch nie Vollast auf seinem Quad. Wozu braucht der also Primeläufe über 12 Stunden, frag ich den öfter.

Oder man denke an diesen Rekordsommer, als reihenweise Hardware ausfiel, weil die Temperaturen weit über Norm lagen. Man muß halt abwägen, und absolute Stabilität unter allen Umständen gibt's eigentlich nicht.

Zu den Freezes hab ich mich geäussert, weil abgesehen von einer dafür bekannten Baureihe der All-In-Wonder vor Jahren, zumindest in meinem Erfahrungsbereich wirklich immer Probleme mit dem RAM gefunden und behoben werden konnten, wenn Systeme freezten. Seit ich im Netz unterwegs bin, also seit 1991. Damals im Z-Netz und im Fido schon, also noch vor dem Internet. Irgendwann singen alle im Chor mit: Ram-a-lam-a-lam-a-lam-a dingdong, wenn irgendwo die Vokabel die Freeze auftaucht. Wenn GraKas freezen, dann eben VRam :)

An VDimm oder V-NB denkt dabei jeder. Aber an andere Parameter weniger. Diverse Timings, Subtimings oder auch Rückwirkungen bei Lastwechseln spielen ja auch 'ne Rolle, wenn Dimms grenzwertig stabil laufen.
 
Zuletzt bearbeitet:
Moin Ango,passiert es manchmal das sich die Prime exe beendet ohne das man was davon merkt?

Also man bekommt keine Meldung das die Exe ein Problem hätte etc.
 
Jap ok da werde ich nicht widersprechen :) ich bin erst 5 Jahre in der Branche..

@Whitecker:ja kann passieren im log siehst normal aber trotzdem wo es aufgehoert hat
 
Ja,ich weiß,das lustige is,ich hab diese grade 1 std Primär laufen lassen,und zwa die 112K,weil nach dem 80K steht nichts mehr in der Log Datei,und dann ist es das,aber habs grade im Custom über std laufen lassen keine Fehler,ich versuch jetzt nochmal Custom durchzubekommen,ey manchmal nervt prime aber auch :d
 
Hi!

Lasse gerade den Largetest laufen, soweit alles gut,doch bei 640K "kackt" immer ein Kern ab.
Dieser Test lotet doch die Kommunkation zwischen den einzelnen Komponenten(CPU/NB/SB usw.)aus,oder?

Müßte ich jetzt versuchsweise mal die MCHCore anheben oder was bedeutet das,das bei 640K ein Kern "aussteigt"?


Kann man eigentlich diesen einzelnen Test irgendwie seperat durchführen ohne immer den gesamten Loop laufen zu lassen?

Also, man ändert eine Spannungseinstellung im BIOS und führt dann den Test seperat durch um erstmal zu schauen,ob die Änderung den gewünschten Erfolg gebracht hat, geht das mit Prime95?


Edit:

Habe mal einen Screen angehangen!
 

Anhänge

  • E8600.jpg
    E8600.jpg
    168,2 KB · Aufrufe: 280
Zuletzt bearbeitet:
Nabend:

mal ne Frage,
kann man eigentlich sichere Rückschlüsse aus dem Fehlerverhalten beim Prime large ziehen ?

Freeze ?
Neustart ohne Blue screen ?
Neustart mit vorherigem Blue screen ?

Danke und Gruß
 
Ich deute einen Freez immer für zu wenig VTT,aber mitlerweile weiß ich das das so nich ganß hinkommt,das kommt immer auf die Config an und so,aber man weiß doch normal ungefair woran es liegt finde ich,zumindest ich weiß immer so ungefair bescheid.
 
Würde mich nur interessieren ob es da Erfahrungswerte gibt, da das "Absturzverhalten" reproduzierbar ist.
Müsste also einen direkten Zusammenhang geben ?
 
generell kannst du das nach meiner Erfahrung net voraussagen. Wenn was am Bus net passt kann theoretisch alles passieren..
 
E8600 und oc(445x9)

Hallo, brauche mal Eure unendliche Weisheit!

Habe zwischenzeitlich einen E8600 erworben und möchte nun die 4Ghz in Angriff nehmen.

Teste gerade 445x9 mittels Prime.
Anbei ein aktueller Screen.Bei dem farblichen Wert handelte es sich um die vorhergehende Spannungseinstellung, bei der
Small mehrere Stunden stabil lief aber Large bereits nach Sekunden eine Fehlermeldung brachte.

Daraufhin habe ich die MCHCore auf 1.22v angehoben, brachte keine Verbesserung.(war eigentlich immer der Meinung, wenn Large "abkackt", dann stimmt in den meisten Fällen die MCHCore nicht...naja Fehlerdenken...)

Also MCHCore auf 1.20v gesenkt und die Vcore auf 1.3v
im BIOS erhöht(warum...weiß ich selber nicht-Gefühlssache?).

Largetest läuft jetzt schon wenigstens 21 Minuten und bricht dann bei 896K ab.

Sollte ich testweise die Vcore noch etwas erhöhen oder eventuell noch eine andere Spannung ändern?

Für Eure Hilfe bin ich sehr dankbar!
 

Anhänge

  • Unbenannt1.jpg
    Unbenannt1.jpg
    137,5 KB · Aufrufe: 277
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