Suchergebnisse

Naja - mit dem 5800X3D hab ich Erfahrung, aber der hat halt nur 1 CCD 😉 Vorher hatte ich einen 5800X, aber da war ich noch nicht so ein CoreCycler Fanboy 😁 Die Theorie macht durchaus Sinn. Je höher der Takt, desto höher die nötige vCore, also desto weniger CO. Wie ich immer wieder sage, CO ist...

v1.4 ist fertig, mit einfacher Installation durch entpacken / kopieren in den RTSS Installationsordner, mit allen RTSS Settings voreingestellt in den Konfig-Files. Inkl. voreingestelltem DesktopOverlayHost für Desktop / 2nd screen. Auch die empfohlenen Einstellungen für FreeSync / G-Sync, V-Sync...

;) Finde es halt beachtenswert, wenn eine solche Koriphäe sich so deutlich äußert zu dem Thema. Hat mich überrascht, deshalb wollte ich drauf hinweisen.

Eh, aber nen Riss merkt man ja nicht, auch nicht im Nachhinein weil dann ja das Pad beim Zerlegen sowieso reißt. Ein Riss würde ja einen Hotspot im Mikrometerbereich bedeuten, und wenn der grad so liegt dass er von Sensoren nicht erfasst wird, ist das sicher nicht gut für die GPU?

Klar: coreTestOrder = 0, 1, 2, 3, 4, 5, 6, 7, 10, 11, 12. 13, 14, 15 Am Schluss dann alles nochmal 12h durchlaufen lassen, gibt auch leichte Abhängigkeiten von "Nachbar-Core-Spannungen", Ich bin genau auf +1 vom Crashwert weg. Musste in ca 2 Jahren 3 Cores um 1-2 nachbessern, also ja...

Agree ;) und danke - genau die hatte ich auch geplant, perfekt!

Was, oder besser wer dagegen spricht, ist Igor im PTM7950 Test: "Ich würde auf einem Wasserblock kein Pad verwenden, jedenfalls kein PCM," Genauer: "Wo ich Probleme sehe, sind Wasserkühler und Wasserblöcke, wo es zumindest auf der Kühlerseite nicht zum vollständigen Phasenwechsel kommen könnte...

Vorsicht ist hier kontraproduktiv, bringt nichts außer dass Du das Unvermeidliche hinauszögerst? Crashen tuts sowieso, das Ziel ist ja möglichst schnell Fehler zu provozieren, um rasch das Limit zu finden und nicht unnötig Strom und Zeit zu verbraten. Also Ich würde in der Mitte starten, also...

Bei mir ist Neustart das übliche "Fehlverhalten", wird durch HNT ausgelöst. WHEA 18 hast Du dann auch automatisch. In meiner Sig findest Du den Link zu meiner Custom-CO Vorgehensweise. Ja, es ist Core 9, CO +1 bei dem Core der Fehler wirft, und nur bei dem - das ist ja der Sinn der Übung.

;)

Nein, Kugelhähne ALS Schnellverbinder, das ist die bewährte Enthusiastenlösung. Keine Durchflussminderung und Standardbauteile. Will nur wissen für welche der beiden Verbindungsvarianten sich @Youngtimer entschieden hat. Und ich denke nicht, dass das nur ein Rohr mit O-Ring drauf ist...

Perfekt, danke auch für den tollen Artikel bei Igor! Frage noch, die Kugelhähne plane ich auch, wie verbindest Du die? Drehbarer Doppelnippel, oder SLI-Verbinder?

Bin grad am planen meines Mo-Ra. Dh Du hast einfach direkt vom Netzteil weg Molex ca 7M verlängert? Das ist kein Problem punkto Spannungsfall?

Wer redet denn von Kinderkupferkühlkörperkonfigurationen. 9x200 ist das Mindeste um meinen Ansprüchen zu genügen!!! Seit gestern um genau zu sein :d PS: ist ja auch der 420 ned sooo viel mächtiger als der 360, 1.7 - 1,1° Unterschied, also... aber trotzdem, der noch ungläubigere Blick meiner...

Grad erst nen 420 Pro gebraucht günstig geschossen, noch nicht mal eingebaut, und schon unglücklich :d

YCRUNCHER_OLD, weil HNT, N64, VST & C17 ersetzt wurden mit N63 und VT3: The HNT, N32, N64, VST, and C17 algorithms are now obsolete. (...) The replacements are N63 and VT3, which are rewrites of the N64 and VST respectively using the new FFT design. Die Tests beim alten yCruncher sind härter...

Wenn Du SMT an hast, zählst Du jedenfalls 0-11 wegen 1+1 phy/virt cores. Also 6 ist dann Core 3 weil 6 / 2 abgerundet = 3. Edit:

Mein Fehler, habs ausgebessert oben, sollte jetzt passen. CoreCycler erkennt Kommentare nur zeilenweise, inline Kommentare mit # nach dem Code resultieren in diesem Fehler.

config.default.ini ist ja auch nur die Vorlage mit Beschreibung, die sollst Du nicht ändern. config.ini wird für die Tests herangezogen, da findest Du oben jede Mange Vorschläge. Für mich funktioniert das hier am besten: Dauert 2min pro Core. Wenn es noch kürzer sein soll mit 30s pro Core...

Passe grad meine Konfigs an die neuen 0.9.5.3 Parameter an. Bei Deinen Prime95 Konfigs oben hast Du meistens runtimePerCore = auto , aber manchmal runtimePerCore = 3m., jeweils ohne testDuration in der Test-Section. Was ist der Hintergrund für die 3m?