CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

bitte bedenke auch das JEDE neue/andere BIOS Version deine mühsam ausgeloteten CO Werte evtl. zunichte machen und du evtl neu ausloten musst 😉
Jein - CO Werte sind ja nicht absolut, sondern relativ zur vCore Baseline - und die ändert sich tw. Deshalb immer die absolute vCore per Core unter Last messen.
Wie? Ich mach das immer mit CoreCycler Kagari und PBO2tuner Monitor. Sollte mit HWinfo aber auch zuverlässig sein.

Damit hast Du dann in absoluten mV die Spannung, die jeder Core stabil braucht, und auf die du einstellst. Allerdings kann sich die auch mit jedem BIOS Update ändern, siehe hier bei mir von 1.2.0.8 auf 1.2.0.A:

1699633587724.png
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
nachdem ich nun endlich eruiert habe,dass der nitromode und nicht die cpu die systemabstürze verursacht hat, will ich nun emdlich meinen 7950x3d per CO einstellen.
welche settings würded ihr für den corecycler empfehlen?
wollte eigentlich den y-cruncher in einem der zusätzlichem modi laufen lassen, aber egal welchem ich einstelle, reklamiert das tool, dass y-crumcher damit nicht läuft... nur der stamdard 00-86 funzt.
reicht der um die stabilität zu tresten?
 
du musst in der config.ini

den "mode" + "~" + "Name" angeben:

für Kagari halt

mode = 19-ZN2 ~ Kagari

nicht nur

mode = 19-ZN2

dann klappt das auch :-)
 
du musst in der config.ini

den "mode" + "~" + "Name" angeben:

für Kagari halt

mode = 19-ZN2 ~ Kagari

nicht nur

mode = 19-ZN2

dann klappt das auch :-)
super, danke.

welchen modus würdest du empfehlen?
versteh von den einzelnen technischen unterschieden definitiv zu wenig...
 
Kagari

Kizuna, welcher eigtl. für Zen4 optimiert ist belastet bei mir die CPU nicht ausreichend. Da kann ich absurd hohe (negative) CO Werte einstellen welche mir dann unter Kakari sofort um die Ohren fliegen
Beitrag automatisch zusammengeführt:

und denk bitte dran deinen RAM vorher auch 100% stabil zu haben - CoreCycler fliegt dir ansonsten um die Ohren aufgrund instabilem RAM und du denkst die CO Werte passen nicht ^^

ansonsten RAM default laufen lassen und mit CoreCycler ausloten

ICH würde allerdings erstmal PBO deaktvieren und den RAM mit dem gewünschten Speed stabilisieren und erst danach PBO CO ausloten 🤓
 
Zuletzt bearbeitet:
Kagari

Kizuna, welcher eigtl. für Zen4 optimiert ist belastet bei mir die CPU nicht ausreichend. Da kann ich absurd hohe (negative) CO Werte einstellen welche mir dann unter Kakari sofort um die Ohren fliegen
Beitrag automatisch zusammengeführt:

und denk bitte dran deinen RAM vorher auch 100% stabil zu haben - CoreCycler fliegt dir ansonsten um die Ohren aufgrund instabilem RAM und du denkst die CO Werte passen nicht ^^

ansonsten RAM default laufen lassen und mit CoreCycler ausloten

ICH würde allerdings erstmal PBO deaktvieren und den RAM mit dem gewünschten Speed stabilisieren und erst danach PBO CO ausloten 🤓
hab nun den ram von expo2 auf default gesetzt und bin inzwischen auf -18 allcore.
mal schauen ob das hält.
mit dem ram auf expo2 crashte mir ein core im normalen corecycler-run schon bei -15.

bin mal gespannt wieviel ich dann bei percore erreiche.
aber das wird eine riesen arbeit, scheiss 16kerner... ^^
 
wenn du EXPO2 später aktivieren willst und du jetzt schon weniger CO einstellen musst nach Aktivierung dessen macht es doch durchaus Sinn wieder EXPO zu aktivieren und erst dann CO auszuloten?!? :fresse:

Wenn RAM jetzt default machst du später alles noch einmal ^^

und ja das einzelne ausloten aller Kerne zieht sich ohne Ende - hab ich bei meinem 12kerner auch durchgemacht :devilish:
 
wenn du EXPO2 später aktivieren willst und du jetzt schon weniger CO einstellen musst nach Aktivierung dessen macht es doch durchaus Sinn wieder EXPO zu aktivieren und erst dann CO auszuloten?!? :fresse:

Wenn RAM jetzt default machst du später alles noch einmal ^^

und ja das einzelne ausloten aller Kerne zieht sich ohne Ende - hab ich bei meinem 12kerner auch durchgemacht :devilish:
stimmt schon, aber einerseits will ich wissen was die cpu kann und beim ram hab ich den verdacht, dass alles noch etwas unstable ist, bzw. noch die eine oder andere kinderkrankheit. zumindest ist das mein gefühl seit ich auf am5 gewechselt habe.
der achsotolle nitro mode hat bei mir nur dazu geführt, dass der ram in memtest tausende fehler und spontane abstürze produzierte. auch sonst bin ich mir nicht sicher, ob expo2 wirklich sauber läuft. hab den ram damals gebraucht gekauft und bin da immer etwas paranoid bei den dingern.
aber ja, wahrscheinlich hast du recht und ich muss mich erstmal um den ram kümmern... da muss ich mich aber erst mal in die materie einlesen.

gibts technische gründe warum die cpu bei stabliem ram @6000 fehlerproduzieren könnte, aber bei default ram nicht? blicke da noch nicht wirklich durch bei dem thema...
 
...
aber ja, wahrscheinlich hast du recht und ich muss mich erstmal um den ram kümmern... da muss ich mich aber erst mal in die materie einlesen.

gibts technische gründe warum die cpu bei stabliem ram @6000 fehlerproduzieren könnte, aber bei default ram nicht? blicke da noch nicht wirklich durch bei dem thema...
unser Ryzen DDR5 OC Thread ist super dafür :-)

bzgl. der "technischen" Gründe kann ich nix sagen, ausser das mein "Gefühl" mir sagt das die CPU ja mit RAM OC mehr belastet wird und weil die ganzen Spannungen da ja mehr oder weniger mit zusammen arbeiten (MCLK alleine reicht nicht nur VDDIO sondern u.U. muss da etwas mehr VSOC etc) würde ich erst RAM und PBO CO machen - kein Vergleich zu meinem Haswell damals der war da nochmals zickiger...
 
unser Ryzen DDR5 OC Thread ist super dafür :-)

bzgl. der "technischen" Gründe kann ich nix sagen, ausser das mein "Gefühl" mir sagt das die CPU ja mit RAM OC mehr belastet wird und weil die ganzen Spannungen da ja mehr oder weniger mit zusammen arbeiten (MCLK alleine reicht nicht nur VDDIO sondern u.U. muss da etwas mehr VSOC etc) würde ich erst RAM und PBO CO machen - kein Vergleich zu meinem Haswell damals der war da nochmals zickiger...
memtest läuft. sobald der fertig ist, mach ich noch 2-3 andere tests und dann gehts ans percore uv.
 
Zuletzt bearbeitet:
eine frage noch, macht es sinn, den corecycler zum testen der gefundenen pbo-settings zusammen mit einem game laufen zu lassen? das dürfte ja durch die zusätzlichen lasten und lastwechsel nochmal anspruchsvoller sein.
oder decken die corecycler-runs das schon ab?
 
Ich habe immer nur CC alleine laufen lassen, war aber auch dem Umstand geschuldet das ich mein AM5 bestimmt 4 Monate ausschließlich "optimiert" habe und nur Test Windows drauf war ohne dedizierte GraKa :banana:

Solange war mein alter Haswell noch weiterhin im Produktivbetrieb
Beitrag automatisch zusammengeführt:

Ich würde aber auch meinen das CC alleine besser sein wird

Wie willst du sonst auch sehen welcher Core genau das System jetzt crasht?!?
 
eine frage noch, macht es sinn, den corecycler zum testen der gefundenen pbo-settings zusammen mit einem game laufen zu lassen? das dürfte ja durch die zusätzlichen lasten und lastwechsel nochmal anspruchsvoller sein.
oder decken die corecycler-runs das schon ab?
Definitiv! Mein 5800x3d ist mit BCLK OC auf 103,375MHz 16h lang CC Kagari stabil, aber bei CC + Overwatch 2 stürzt er nach spätestens 1h ab (Reboot) . OK, man kann sagen das ist "ziemlich alltagsstabil", aber 8ch habs halt gern 100% stabil... Und das ist halt leider nur bei BCLK 100MHz.
 
bin zwar noch nicht fertig mit ausloten, aber hab gestern nach etlichen ycruncher runs mal einen prime avx2 gemacht. quasi instant reboot... XD
 
Definitiv! Mein 5800x3d ist mit BCLK OC auf 103,375MHz 16h lang CC Kagari stabil, aber bei CC + Overwatch 2 stürzt er nach spätestens 1h ab (Reboot) . OK, man kann sagen das ist "ziemlich alltagsstabil", aber 8ch habs halt gern 100% stabil... Und das ist halt leider nur bei BCLK 100MHz.
von BLCK OC lasse ich dir Finger weil ich damit eher durchwachsene Erfahrungen gemacht habe - und das obwohl meine Board einen BLCK Generator besitzt ^^

des weiteren tut es mit leid aber dann hast du beim ausloten wohl etwas eklatant falsch gemacht :unsure:

ich habe Wochen damit verbracht mein PBO CO pro Core bis auf den letzten Schritt auszuloten - ja das war teilweise massiv nervig, auch weil schon zigmal durchgelaufene Kerne dann doch wieder ausgestiegen sind. Die PBO CO Werte beeinflussen sich gegenseitg.

D.h. wenn du Core 3 weiter absenkst zeiht es u.U. Core 2 UND Core 4 auch minimalst mit runter - so das du da nochmals gegenprüfen musst!

Genauso ist es bei mir das ich 3 Kerne ins "positive" nehmen muss - obwohl alle anderen fett ins "negativ" können

Ebenfalls ist es massiv abhänig ob du auch den "richtigen" Ycruncher "mode" benutzt - ob du bei SMT fähigen CPUs auch 2 Threads laufen lässt und noch so einiges

Prime ist als CC Test total unzuverlässig m.e.

Bei mit ist das für den Zen4 empfohlene Kizuna nämlich "pippifax" damit kann ich absurd hohe (negative) Werte einstellen welche überhaupt nicht alltagsstabil sind!
Nur Kagari lastet entsprechend realitätsnah aus

Meine config's findest du ein paar Seiten weiter vorne - insgesamt reicht es bei meinem 12-Kerner auch nicht den CC "mal so 1-2h laufen zu lassen"

Ich bin der Meinung 24h minimum um eine Mindestmaß an Stibilität zu garantieren - was ja "Pro Kern" bei mir dann auch nur 2h entspricht

Kann jeden verstehen dem das zu aufwendig ist ABER dann sollen diejenigen sich bitte nicht wundern das deren System Idle Reboots oder Game crashes oder sonstwie instabil läuft :fresse:

ich habe mir die Mühe gemacht vorher meinen RAM 100% stabil zu machen - da reicht übrigens nicht nur Karhu oder tm5 -> 16-24h prime large fft und ihr werdet euch wundern wie schnell euer (durch tm5/karhu stabiles) RAM OC euch um die Ohren fliegt

DANN erst PBO CO mit CC ausloten... wenn dann auch das Thema durch ist hast derjenige ein in meinen Augen 99.99999% stabiles System

Ich habe z.B. noch nie weder einen Game Crash oder andere sonstige Unklarheiten mit meinen System verzeichnet - ich re-encode auch viel x265 Handbrake :devilish:

Daher "traue" ich mich aktuell aber auch nicht wirklich drann ein neueres BIOS zu flashen - von 1004 auf meine jetziges 1405 musste ich nämlich nicht nur den RAM neu anpassen sondern auch meine PBO CO Werte teilweise massiv ändern...

Zu deiner Testmethode CC gleichzeitig mit einem Spiel laufen zu lassen -> ich verstehe da nicht wie du dann wissen willst welcher Core denn jetzt den Crash ausgelöst hat

Beim CC ist doch gerade der Vorteil das nur der einzelnen Core welcher gerade getestet wird entsprechend ausgelastet wird und du genau diesen entsprechend nachjustieren kannst ^^

aber btw. das o.g. ist auch alles in diesen Thread nachzulesen - die Mühe muss sich nur jemand machen dies dann auch lesen zu wollen :hust:

und wie immer gilt: das zuvor geschriebene stellt nur meine persönlichen Erfahrungen mit meinen Zen4 System dar - ich hatte davor gut 10 Jahre einen 4790k

trotzdem sollte es mich wundern wenn die Erfahrungen und Ergebnisse nicht auf andere Zen4 Systeme 1:1 übertragbar wären was PBO CO angeht :coolblue:
 
Zuletzt bearbeitet:
Zu deiner Testmethode CC gleichzeitig mit einem Spiel laufen zu lassen -> ich verstehe da nicht wie du dann wissen willst welcher Core denn jetzt den Crash ausgelöst hat
Beim CC ist doch gerade der Vorteil das nur der einzelnen Core welcher gerade getestet wird entsprechend ausgelastet wird und du genau diesen entsprechend nachjustieren kannst ^^


und wie immer gilt: das zuvor geschriebene stellt nur meine persönlichen Erfahrungen mit meinen Zen4 System dar - ich hatte davor gut 10 Jahre einen 4790k
ich denke die idee von cc mit game laufen zu lassen ist eher als eine art finaler test zu verstehen. so quasi wenn alles durch läuft noch ein game zusätzlich um zu schauen obs hält.
keine ahnung ob das was bringt und wenns dann doch noch einen fehler gibt, weiss man nicht wo suchen...

hab auch von einem 4790 auf einen 7000er ryzen gewechselt.
:giggle:(y)

was mich momentan etwas iritiert ist das von dir angesprochene zusammenhängen der kerne... habe immerwieder mal einen kern, der gut lief und dann plötzlich wieder permanent fehler produziert und mehr saft braucht. ist echt schwierig das kernverhalten abzuschätzen. ganz allgemein scheint bei meinen kernen aber ein -25 das max zu sein. wobei die meisten bei -18 und einige wenige bislang bei -14 stehen. aber bin da noch lange nicht fertig damit...
 
von BLCK OC lasse ich dir Finger weil ich damit eher durchwachsene Erfahrungen gemacht habe - und das obwohl meine Board einen BLCK Generator besitzt ^^

des weiteren tut es mit leid aber dann hast du beim ausloten wohl etwas eklatant falsch gemacht :unsure:
Du vermischt hier @huberei (der Kollege mit dem Problem ;)) und mich in Deiner Antwort kommt mir vor? Ich habe nur die Erfahrung mit Y-Cruncher + Game wiedergebeben, die auch nur bei BCLKC OC ein Thema war. Wüsste nicht was ich falsch gemacht habe, wenn bei mir (wie offenbar auch bei Dir) nur bei BCLK OC Probleme auftreten, und sonst alles 100% stabil ist ;)
ich habe Wochen damit verbracht mein PBO CO pro Core bis auf den letzten Schritt auszuloten - ja das war teilweise massiv nervig, auch weil schon zigmal durchgelaufene Kerne dann doch wieder ausgestiegen sind. Die PBO CO Werte beeinflussen sich gegenseitg.

D.h. wenn du Core 3 weiter absenkst zeiht es u.U. Core 2 UND Core 4 auch minimalst mit runter - so das du da nochmals gegenprüfen musst!
Ganz genau, kann ich bestätigen - das dauert einige Runden lang, und Cores die stundenlang stabil waren, sind es plötzlich nicht mehr wegen einer Änderung an einem anderen Core.
Ebenfalls ist es massiv abhänig ob du auch den "richtigen" Ycruncher "mode" benutzt - ob du bei SMT fähigen CPUs auch 2 Threads laufen lässt und noch so einiges
Das ist klar, Kagari + 2 Threads ist angesagt. Bei mir gabs bei HNT immer Reset, ich hab aber auch 64GB die ich mit 3800 betreibe, hängt ev auch damit zusammen.
ich habe mir die Mühe gemacht vorher meinen RAM 100% stabil zu machen - da reicht übrigens nicht nur Karhu oder tm5 -> 16-24h prime large fft und ihr werdet euch wundern wie schnell euer (durch tm5/karhu stabiles) RAM OC euch um die Ohren fliegt
Interessant! Einfach All-Core Lare FFT mit SMT?
Ich habe z.B. noch nie weder einen Game Crash oder andere sonstige Unklarheiten mit meinen System verzeichnet
Same here ;)
Daher "traue" ich mich aktuell aber auch nicht wirklich drann ein neueres BIOS zu flashen - von 1004 auf meine jetziges 1405 musste ich nämlich nicht nur den RAM neu anpassen sondern auch meine PBO CO Werte teilweise massiv ändern...
Bei mir laufen dieselben RAM Timings, aber CO musste ich tw um 30-40mV anpassen (Zen3):
1704611282630.png

Zu deiner Testmethode CC gleichzeitig mit einem Spiel laufen zu lassen -> ich verstehe da nicht wie du dann wissen willst welcher Core denn jetzt den Crash ausgelöst hat
Beim CC ist doch gerade der Vorteil das nur der einzelnen Core welcher gerade getestet wird entsprechend ausgelastet wird und du genau diesen entsprechend nachjustieren kannst ^^
Ganz einfach, im YC Log nachschauen - da steht der zuletzt genutzte ;)
 
ich denke die idee von cc mit game laufen zu lassen ist eher als eine art finaler test zu verstehen. so quasi wenn alles durch läuft noch ein game zusätzlich um zu schauen obs hält.
keine ahnung ob das was bringt und wenns dann doch noch einen fehler gibt, weiss man nicht wo suchen...
genau so sehe ich das auch... nehmen wir an ein Spiel nutzt 8 Threads - zusätzlich läuft mit CC ein weiterer Kern, jetzt belastet das Game u.U. einige Kerne welche noch nicht stabil sind. Somit crasht dir das Spiel auf den Desktop und du suchst dir einen Wolf weil unklar welcher Core jetzt diesen Crash verursacht hat

was mich momentan etwas iritiert ist das von dir angesprochene zusammenhängen der kerne... habe immerwieder mal einen kern, der gut lief und dann plötzlich wieder permanent fehler produziert und mehr saft braucht. ist echt schwierig das kernverhalten abzuschätzen. ganz allgemein scheint bei meinen kernen aber ein -25 das max zu sein. wobei die meisten bei -18 und einige wenige bislang bei -14 stehen. aber bin da noch lange nicht fertig damit...
das ist genau das was mich zum Schluß ehrlich gesagt wahnsinnig gemacht hat - diverse Kerne sind dann obwohl vorher 24h run stabil, den nächsten run trotzdem immer wieder mal ausgestiegen. Jetzt muß ich für mein Systen dazu sagen das ausloten bis auf den letzten Zähler natürlich nicht den Standard darstellt - aber mich hatte den Ehrgeiz gepackt das "in den Griff" zu kriegen ^^

Wenn du dich mit allen Kernen zum Schluß so ziemlich am Limit befindest ist das besonders nervig wenn dann immer mal wieder ein Kern aussteigt obwohl tagelang vorher "stable"

Zu Anfang wenn die einzelnen Cores noch ausreichend Luft zu ihren CO Limit haben fällt das nicht auf wenn du z.B. Core3 absenkst das dann Core2 + Core4 auch minimalst weniger Spannung bekommen. Umso mehr du aber ins Limit kommst desto krasser agieren die unmittelbar umliegenden Kerne auch auf weitere Absenkungen.

Du vermischt hier @huberei (der Kollege mit dem Problem ;)) und mich in Deiner Antwort kommt mir vor? Ich habe nur die Erfahrung mit Y-Cruncher + Game wiedergebeben, die auch nur bei BCLKC OC ein Thema war. Wüsste nicht was ich falsch gemacht habe, wenn bei mir (wie offenbar auch bei Dir) nur bei BCLK OC Probleme auftreten, und sonst alles 100% stabil ist ;)
Mea Culpa, das mit CC + Game tritt ja nur bei BCLK OC bei dir auf - das hatte ich leider überlesen ^^

Ganz genau, kann ich bestätigen - das dauert einige Runden lang, und Cores die stundenlang stabil waren, sind es plötzlich nicht mehr wegen einer Änderung an einem anderen Core.
(y) so auch meine Erfahrung

Interessant! Einfach All-Core Lare FFT mit SMT?
korrekt, Settings welche bei mir TM5 (1usmus, anta extreme, anta absolut) & Karhu (20000%) locker überstehen - rasuchen mir innerhalb 30-60 min im Prime ab
Prime large FFT AVX SMT ist für mich - auf meinem System - der Endgegner :devilish:

prime95 large fft avx.PNG


Deshalb finde ich es immer seeeehr amüsant wenn im Netz (ob hier, auf ocn, oder CB) von RAM OC Stabilität gesprochen wird, weil eben tm5 und karhu "stabil sind" aber gleichzeitig Prime95 als völlig überflüssig abgetan wird

Bei mir laufen dieselben RAM Timings, aber CO musste ich tw um 30-40mV anpassen (Zen3):
Danke für den Excel Auschnitt

Werde definitv noch einige BIOS Versionen warten bis sich in den Changelogs/Fixes was für mich sinnvolles ändert :-)

Ganz einfach, im YC Log nachschauen - da steht der zuletzt genutzte ;)
ich zitiere hier mal meine vorherige Antwort an @huberei

genau so sehe ich das auch... nehmen wir an ein Spiel nutzt 8 Threads - zusätzlich läuft mit CC ein weiterer Kern, jetzt belastet das Game u.U. einige Kerne welche noch nicht stabil sind. Somit crasht dir das Spiel auf den Desktop und du suchst dir einen Wolf weil unklar welcher Core jetzt diesen Crash verursacht hat

Sollte dies natürlich nur als "Endtest" vorgesehen sein stimme ich allerdings zu - umso mehr verschiedene Belastungszustände du simulieren/herstellen kannst um das System maximal zu stressen und es läuft trotzdem sauber weiter -> umso besser
 
nachdem mir prime die mit y-cruncher ermittelten werte so richtig zerschossen hat, hab ich nun wieder ganz unten mit prime avx2 angefangen.
das einzige was wirklich konstant ist, sind die kerne die mehr saft brauchen, aber die stabilen werte sind verglichen mit y-cruncher doch deutlich niedriger.
auffällig ist, dass die error immer erst bei den huge files auftreten. das dürfte wohl auch der grund sein, wieso es in y-cruncher lief. der mag in den 10min intervals wohl nicht bis zu den wirklich grossen files durchtesten.
 
Prime AllCore?

Wie lange hattest du CC ycruncher am Stück durchlaufen lassen?
 
Prime AllCore?

Wie lange hattest du CC ycruncher am Stück durchlaufen lassen?
prime und auch y-cruncher im CC liefen pro kern ca. 10min und das habe ich jeweils über Nacht durchlaufen lassen. Also pro Lauf waren das im Schnitt 8-10 Stunden.
 
nur das ich das richtig verstehe, ycruncher CoreCycler läuft durch und dann Prime CoreCycler bricht ab?

Kannst du mal bitte deine CC config Posten welche mit ycruncher lief?
 
nur das ich das richtig verstehe, ycruncher CoreCycler läuft durch und dann Prime CoreCycler bricht ab?

Kannst du mal bitte deine CC config Posten welche mit ycruncher lief?
ja genau so. habs mit dem von dir empfohlenen test laufen lassen. werde heute abend mal schauen, und dir den screenshot schicken.
 
ja genau so. habs mit dem von dir empfohlenen test laufen lassen. werde heute abend mal schauen, und dir den screenshot schicken.
sorry, bin nicht mehr dazu gekommen. was ich aber gesehen habe, der y-cruncher kagari prüft kein avx2, von daher nicht verwunderlich, dass prime avx2 dann etwas andere resultate lieferte...
 
werde CC Prime mit AVX2 später auf meinem System gegen testen - bin mir bisher sicher gewesen, daß Kagari das System unter CC am härtesten belastet...

Wenn ich mich nicht vertue taktet die CPU unter AVX2 doch auch gar nicht so hoch...?!?
 
werde CC Prime mit AVX2 später auf meinem System gegen testen - bin mir bisher sicher gewesen, daß Kagari das System unter CC am härtesten belastet...

Wenn ich mich nicht vertue taktet die CPU unter AVX2 doch auch gar nicht so hoch...?!?
Keine Ahnung. Verstehe davon wirklich nicht zuviel. Aber was mir aufgefallen ist, die Errors kamen immer bei den Huge files in prime.
 
@huberei

kann dein Problem mit CC Prime AVX2 - nach ausschliesslichem ausloten mit Kagari - auf meinem System nicht nachvollziehen:

CC_prime_avx2_huge#1.PNG CC_prime_avx2_huge#2.1.PNG

4h Laufzeit - alles i.O. (hatte ich aber auch nicht anders erwartet, dafür läuft mein System einfach zu stabil)

wenn ich allerdings mutmaße das "huge" bei CoreCycler Prime das äquivalent zu "large FFT" bei Prime95 darstellt würde ich behaupten das evtl. dein RAM nicht 100% stabil ist?!?

Prime_large_fft_RAM.PNG

wenn es daran nicht liegt wäre das ziemlich strange warum dein System sich anscheinend komplett anders verhält als meins ^^
 
Zuletzt bearbeitet:
@huberei

kann dein Problem mit CC Prime AVX2 - nach ausschliesslichem ausloten mit Kagari - auf meinem System nicht nachvollziehen:

Anhang anzeigen 957945 Anhang anzeigen 957946

4h Laufzeit - alles i.O. (hatte ich aber auch nicht anders erwartet, dafür läuft mein System einfach zu stabil)

wenn ich allerdings mutmaße das "huge" bei CoreCycler Prime das äquivalent zu "large FFT" bei Prime95 darstellt würde ich behaupten das evtl. dein RAM nicht 100% stabil ist?!?

Anhang anzeigen 957947

wenn es daran nicht liegt wäre das ziemlich strange warum dein System sich anscheinend komplett anders verhält als meins ^^
hole mal eines der logs raus. kann den ram noch nicht 100%ig ausschliessen. sobald ich zeit hab, kümmere ich mich nochmal intensiv darum. danke für dein feedback!
 
...kann den ram noch nicht 100%ig ausschliessen...
einfach Prime95 mit den von mir im Screenshot empfohlenen Einstellungen laufen lassen

ich lasse einen Run dann immer 24h als Endtest laufen - sollten 8-12h problemlos möglich sein wird der Ram auch schon zu 95% stabil sein

Prime95 ist war schon immer für meine System der Endgegner - erst wenn das entsprechend lange problemlos durchläuft bin ich happy 😇:banana:

aber denk bitte dran dafür PBO temporär zu deaktivieren - sonst grätschen dir u.U. deine angepassten/ab Werk nicht 100% stabilen PCO CO Einstellungen dazwischen
 
Prime95 Large war jetzt auch 4h lang kein Problem. Allerdings lass ich TM5 auch 7h laufen (nicht wie die meisten 1-2), und CC 12-24h.

Prime hat halt den großen Nachteil, dass es extrem viel auf die Platte schreibt:
1705223742314.png


Das obere ist die Anwendungs- und Spiele-SSD, das untere die System-SSD mit Prime95. Zack, mal eben 20% Lebensdauer runtergetestet ;) Aber hab auch seeehr viel Prime getestet, bevor ich den CoreCycler + Y-Cruncher & TM5 entdeckt habe, die das eben deutlich effizienter per Core machen bzw halt auf den Speicher Danke dafür @sp00n ;)
 
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