Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Es lag wohl an den Spannungen... tWRRD 1 statt neu 2 wird nicht für die Neustarts verantwortlich gewesen sein. Ich hatte im letzten Run VDD / VDDQ / VDDIO um 0,2V gesenkt und prompt gab es nach ~25 Min. den Neustart. VDDIO wieder 0,2V hoch und Blend lief 45 Min durch. Ich probiere gleich VDD und VDDQ um 0,2V runter... VDDQ kann ich ja quasi frei einstellen, nur nicht über VDD gehen.
Auf der 1. Seite steht, das VDD und VDDIO gleich eingestellt sein sollen - ist aber kein Muss, korrekt? Würde dann VDDIO auf 1,4V eher Stress oder bessere Stabilität bedeuten?
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hab jetzt mal mit den alten Settings Karhu laufen lassen, hab aber die VDD zumindest mal runtergedreht. 1,47V hat fehler bei 300% geworfen, 1,50V lief jetzt über Nacht durch. Nur wenn ich jetzt anfange an den anderen Timings zu drehen geht das ganze ganz schnell in 2F, 2A oder manchmal im zweiten Training sogar 00 im DEBUG, da ging mir schon kurz die Muffe.
1,5V VDD für deine Timings ist gut. Weiter herunter kommst du auch mit noch besseren Kits nicht, hängt einfach von mehreren Faktoren ab.
Du könntest noch das probieren. In Karhu fehlen dir noch 3MB/s, ist halt auch aus dem RRD_L & WTR_L geschuldet. Du kannst für RDD_L = 8 & WTR_L = 16 probieren. tWRWRSCL sollte eigentlich auch mit 1 laufen, ändere aber erstmal nur schrittweise.
Auf der 1. Seite steht, das VDD und VDDIO gleich eingestellt sein sollen - ist aber kein Muss, korrekt? Würde dann VDDIO auf 1,4V eher Stress oder bessere Stabilität bedeuten?
VDDIO & VDDQ sind bis 1,5V "safe". Viele CPUs mögen aber keine hohen VDDIO Spannungen weswegen hier meist 1,45V das Limit ist, sieht man auch an den ganzen Expo/XMP Profilen.
VDD/Q kann man im Alltag bis +1,51V oder höher (kommt auf die Kühlung an) betreiben. VDDQ muss auch nicht VDDIO matchen, es kann aber der Stabilität zugutekommen.
Die Spannungen welche die CPU wirklich belasten & Energie fressen sind VSOC & CLDO VDDP.
Es wird sich im Endeffekt nicht viel schenken. Solange dein FCLK bei 2200 stabil ist, würde ich es so belassen. Die paar MB mehr Bandbreite beim single CCD wäre mir wichtiger.
Da ich nach Beitrags-Meldungen @Tatilica dazu gerade schon per PM angeschrieben habe und mir dies auf den letzten Seiten auch bei anderen Usern aufgefallen ist, hier auch noch mal der allgemeine Hinweis für alle:
Bitte bindet Screenshots in hohen Auflösungen (FHD+) ausschließlich als Thumbnails und nicht als Full Size Images ein.
Selbiges gilt für Beiträge, die mehr als ein einzelnes Bild enthalten. Man kann im Forum zwischen mehreren eingebetteten Grafiken blättern.
Bilder sind gemäß §7 der Forenregeln aus Zitaten zu entfernen. Der Bezug wird durch den Beitragslink (weißer Pfeil) trotzdem klar.
All dies dient der besseren Lesbarkeit des Forums, nicht nur für Mobile User.
Ycruncher is a good tool and you should run all the tests there to generate enough stress and heat on the CCDs and IOD, because the high heat development often causes problems (especially with the IOD).
Hi, maybe I'll do all checked tests some day, but I always kept my own stability testing route for Ryzen, suggested here on Luxxe by master Jedi @Veii itself, it was my first lesson received from him years ago, whom I salute him by this way coz we miss him much on Luxxe already 🙏
I never saw someone here using Ycruncher N64 combo FFT/VT3, why just but only Karhu or only TM5 alone, coz I know surely your CO-30+ in range won't work and will crash by cores in no time if not stable enough, that's why y don't following better this route posted Here in a profi matter way 🙃
With TM5 50cycles passed on both 1usmus or Absolut in early debut mems testing, for checking timings only, and after than 50cycles Ycruncher FFT/N64/VT3 for harder AVX2 datashet scenario, you'll find your stability soon, and if all fine & passed well all stable, lately final run Karhu test with Cpu cache Enabled minimun 12h+ or 24h for better confidence will validate y Profile as stable indeed.
Frame times and frame drops are a good indicator of whether settings are working or not. Especially in games, different areas of the CPU are dynamically loaded, which can detect some errors and lead to crashes.
Oh boy, I did tested at last CP Liberty and founded lately harder Starfield on most demanding workload, coz was frezzing my build in no time cause wrong mems setup & CO-30 too short indeed, I can tell 👍
Anhang anzeigen 1062604
I always try to do a multi step approach, so my "stable" (which everyone defines differently of course) is more like: TM5 1usmus for identifying issues quickly (~1,5h), then 2-3h TM5 anta777 (more temperature on RAM) and then going over to 25k+ on Karhu. Normally then also followed by some hours of P95 Blend (for overall stability). Then some rounds of BF5 as this was in the past also very itchy in my experience.
Hi, understood your stable route, very similar to mine, posted already to @Vince96 my way, just but I find always Prime more appropiate for Intel scenario, due to his different way approach of testing parts and Ycruncher & his harder testing suite, which fit better for Ryzen 👍
As for gaming, yeah Starfield stays my harder preffered one for stable testing scenario, cheers!
Wo finde ich den Gear Down Mode? Ich habe das gesamte Bios durchforstet und nur einen "Power Down Mode" gefunden, der scheint aber etwas anderes zu sein.
Außerdem: Ist es normal, dass bei FCLK 2200 MHz die Latenz um 15ns hochgeht?
Wo finde ich den Gear Down Mode? Ich habe das gesamte Bios durchforstet und nur einen "Power Down Mode" gefunden, der scheint aber etwas anderes zu sein.
Außerdem: Ist es normal, dass bei FCLK 2200 MHz die Latenz um 15ns hochgeht?
Das kann ich dir bei Gigabyte nicht sagen, es gibt aber im Bios unten rechts ein Lupe Symbol womit du es suchen kannst.
Die Latenz wird steigen aber 15ns ist viel, kann auch am GDM & oder an instabilen Timings liegen.
VDDIO & VDDQ sind bis 1,5V "safe". Viele CPUs mögen aber keine hohen VDDIO Spannungen weswegen hier meist 1,45V das Limit ist, sieht man auch an den ganzen Expo/XMP Profilen.
VDD/Q kann man im Alltag bis +1,51V oder höher (kommt auf die Kühlung an) betreiben. VDDQ muss auch nicht VDDIO matchen, es kann aber der Stabilität zugutekommen.
Die Spannungen welche die CPU wirklich belasten & Energie fressen sind VSOC & CLDO VDDP.
Ok, dann ist ja alles safe mit meinen Einstellungen... Hatte heute den ganzen Tag Blend getestet und das läuft jetzt stabil - also sofern einem 2 Std. ausreichen.
Ich war gar nicht soweit weg, am Ende waren es nur kleine Schritte (Neu / Alt). Teils konnte ich die Spannungen sogar noch etwas verringern. Vllt. hätte es letzte Woche auch gereicht, nur VDDIO leicht zu erhöhen. Da ich aber alle Spannungen angehoben hatte, blieb die Differenz ja gleich groß uns so kam keine Stabilität rein.
Gibt es irgendwelche Einwände?
edit: Karhu ist auch durch... nun hoffe ich, das alles passt.
Wo finde ich den Gear Down Mode? Ich habe das gesamte Bios durchforstet und nur einen "Power Down Mode" gefunden, der scheint aber etwas anderes zu sein.
Außerdem: Ist es normal, dass bei FCLK 2200 MHz die Latenz um 15ns hochgeht?
Zuerst mal Ycruncher da das bei mir zuerst abkackt (allerdings auch wenn die CPU Settings nicht passen) , mal sehen ob das auch längerfristig stabil ist, ich kann´s mir nicht vorstellen imho alleine wegen der relativ niedrigen Spannungen.
Ich fahr nen relativ "normales" 6000er Profil. Standard Win11 mit entsprechender RAM Auslastung und Hintergrundprozessen (und damit Einbußen im AIDA Bench).
Irgendwas ist da gerade borderline stable bei mir, hab versucht erstmal die Spannungen noch leicht zu senken, das lief aber dann doch in Probleme (VDDIO 1,4 - 1,425 + VDDQ bis 1,4 runter). Mal Karhu, dann wieder TM5. Dann hab ich Reset auf die Settings von heute Nacht und jetzt fliegt mir TM5 wieder...
Muss ich morgen nochmal VDIMM erhöhen und nochmal die alte Baseline wiederfinden :/
Ich fahr nen relativ "normales" 6000er Profil. Standard Win11 mit entsprechender RAM Auslastung und Hintergrundprozessen (und damit Einbußen im AIDA Bench).
Hoschi hat auch 6800er RAM und fährt 1,5v auf dem RAM, dass ist mir doch zu heftig
Aber vermutlich sind meine 69,2ns gar nicht so schlecht im Vergleich zur Basis.
1,435V VSOC 👀 - geht doch eigentlich gar nicht , waren die nicht per agesa per se auf 1,3V max beschränkt oder kann das ein Auslesefehler sein aus dem ersten Link......
Hoschi hat auch 6800er RAM und fährt 1,5v auf dem RAM, dass ist mir doch zu heftig
Aber vermutlich sind meine 69,2ns gar nicht so schlecht im Vergleich zur Basis.
In beiden geposteten Bildern, wie auch im verlinkten Beitrag von Hoschi, geht es ausschließlich um 6000er Profile. Welche RAM Sticks du verwendest, ist erstmal ein anderes Thema.
1,435V VSOC 👀 - geht doch eigentlich gar nicht , waren die nicht per agesa per se auf 1,3V max beschränkt oder kann das ein Auslesefehler sein aus dem ersten Link......
Die SWAP APU Geschichte habe ich btw wieder deaktiviert. Man gewinnt 400 MB/s im Read, verliert aber 2.000 MB/s im Copy. Zumindest mir ist es das nicht wert.
Zum Thema synchrone tPHYRDL, die CLDO VDDp oder andere Spannungen oder gar Widerstände anpassen, hat bei mir gar nichts gebracht was das synchrone Training der tPHYRDL auf beiden Bänken angeht.
Was bei mir aber endlich geholfen hat, das er die tPHYRDL auf beiden Bänken gleich trainiert, ist die Option: ARdPtrInitVal P0 Control auf 1. Man kann da 0, 1 oder 2 probieren. Und siehe da, er trained endlich nicht mehr unterschiedlich auf A2/B2.
Das nur mal als Tip, ich denke das läuft ja bei dem ein oder anderen unsynchron. Performance bringt es keine, aber zumindest wäre mal ein Weg gezeigt, wie man das auf 9000-Series tatsächlich fixen kann! Die Option ARdPtrInitVal P0 Control ist im BIOS nämlich nur für die 9000-Series verfügbar!
Statt 35/37 (AUTO) trainied er mit Init Val bei mir mit 1 35/35, mit 0 trained er 33/35, also wieder asynchron. Das muss man testen.
Die SWAP APU Geschichte habe ich btw wieder deaktiviert. Man gewinnt 400 MB/s im Read, verliert aber 2.000 MB/s im Copy. Zumindest mir ist es das nicht wert.
Zum Thema synchrone tPHYRDL, die CLDO VDDp oder andere Spannungen anpassen, hat bei mir gar nichts gebracht was das synchrone Training der tPHYRDL auf beiden Bänken angeht.
Was bei mir aber endlich geholfen hat, das er die tPHYRDL auf beiden Bänken gleich trainiert, ist die Option: ARdPtrInitVal P0 Control auf 1. Man kann da 0, 1 oder 2 probieren. Und siehe da, er trained endlich nicht mehr unterschiedlich auf A2/B2.
Das nur mal als Tip, ich denke das läuft ja bei dem ein oder anderen unsynchron. Performance bringt es keine, aber zumindest wäre mal ein Weg gezeigt, wie man das tatsächlich fixen kann!
Ich bin sicher nicht auf dem Level von 
