News AMD Ryzen 5000: CoreCycler aus der Community optimiert den Curve Optimizer

Wird dir wohl nicht viel helfen, aber bitte schön:
+ Trying to get the localized performance counter names
+ ID of "ID Process": 784
+ ID of "% Processor Time": 6
+ ID of "Process": 230
+ The localized name for "Process": Prozess
+ The localized name for "ID Process": Prozesskennung
+ The localized name for "% Processor Time": Prozessorzeit (%)
+ FullName: \Prozess(*)\Prozesskennung
+ SearchString: \\Prozesskennung$
+ ReplaceString: \Prozessorzeit (%)
+ Initalizing the stress test program
+ Checking if prime95.exe exists at:
+ F:\Tools\CoreCycler-v0.8.0.0-RC3\test_programs\p95\prime95.exe
--------------------------------------------------------------------------------
------------ CoreCycler v0.8.0.0 RC3 started at 2021-03-28 15:01:59 ------------
--------------------------------------------------------------------------------
Verbose mode is ENABLED: .. Writing to log file
Stress test program: ...... PRIME95
Selected test mode: ....... SSE
Logical/Physical cores: ... 24 logical / 12 physical cores
Hyperthreading / SMT is: .. ON
Selected number of threads: 1
Runtime per core: ......... 6 minutes
Suspend periodically: ..... ENABLED
Test order of cores: ...... DEFAULT (ALTERNATE)
Number of iterations: ..... 10000
Selected FFT size: ........ Huge (8960K - 32768K)
--------------------------------------------------------------------------------
The log files for this run are stored in:
F:\Tools\CoreCycler-v0.8.0.0-RC3\logs\
  • CoreCycler: CoreCycler_2021-03-28_15-01-55_PRIME95_SSE.log
  • Prime95: Prime95_2021-03-28_15-01-55_SSE_Huge_FFT_8960K-32768K.txt
--------------------------------------------------------------------------------

+ Starting the stress test program
+ Starting Prime95
+ Trying to get the stress test program window handler
+ Looking for these window names:
+ ^Prime95 \- Self\-Test$, ^Prime95 \- Not running$, ^Prime95 \- Waiting for work$, ^Prime95$
+ 15:02:00 - Window found
+ Found the following window(s) with these names:
+ - WinTitle: Prime95 - Self-Test
+ ProcessId: 13052
+ Process Path:
+ Filtering the windows for ".*prime95.exe$":
+ Stress test window handler:
+ Stress test window process ID:
+ Stress test process: prime95
+ Stress test process ID:
FATAL ERROR: Could not find the counter path for the Prime95 instance!

Wohl anders als bei anderen, die dir scheinbar den gleichen Fehler gemeldet haben...Funktioniert es bei mir nun kein einziges mal mehr.
Das Tool ist für mich TOT deswegen.
Wie gesagt...im Prime Fenster kann man sehen es macht seie Sache weiter, aber ohne Feedback welcher Kern es denn dann wäre ist es komplett nutzlos.
 
Rodger schrieb:
Wohl anders als bei anderen, die dir scheinbar den gleichen Fehler gemeldet haben...Funktioniert es bei mir nun kein einziges mal mehr.
Bei dir ist das anscheinend ein anderer Fehler, bei dir wird warum auch immer zwar das Fenster anhand des Titels gefunden, aber es kann dann dazu nicht der Pfad der ausgeführten Datei ausgelesen (und verglichen) werden. 🤨

Ich hab mal versucht, den Pfad direkt zu integrieren anstatt da den Umweg über PowerShell zu gehen. Was spuckt dir denn dieses PowerShell-Script aus, nachdem das CoreCycler-Script mit dem Fehler abgebrochen hat?

PowerShell:
$GetWindowsDefinition = @'
    using System;
    using System.Text;
    using System.Collections.Generic;
    using System.Runtime.InteropServices;
  
    namespace GetWindows {
        public class WinStruct {
            public string WinTitle {get; set; }
            public int MainWindowHandle { get; set; }
            public string ProcessPath { get; set; }
            public int ProcessId { get; set; }
        }
       
        public class Main {
            private static int PROCESS_QUERY_INFORMATION = (0x00000400);
            private static int PROCESS_VM_READ           = (0x00000010);

            private delegate bool CallBackPtr(int hwnd, int lParam);
            private static CallBackPtr callBackPtr = Callback;
            private static List<WinStruct> _WinStructList = new List<WinStruct>();


            [DllImport("user32.dll")]
            [return: MarshalAs(UnmanagedType.Bool)]
            private static extern bool EnumWindows(CallBackPtr lpEnumFunc, IntPtr lParam);

            [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
            static extern int GetWindowText(IntPtr hWnd, StringBuilder lpString, int nMaxCount);
          
            [DllImport("user32.dll", CharSet = CharSet.Auto, SetLastError = true)]
            static extern int GetWindowThreadProcessId(IntPtr hWnd, out int ProcessId);

            [DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
            static extern int OpenProcess(int dwDesiredAccess, bool bInheritHandle, int dwProcessId);

            [DllImport("psapi.dll", CharSet = CharSet.Auto, SetLastError = true)]
            static extern int GetModuleFileNameEx(IntPtr hProcess, IntPtr hModule, StringBuilder lpFilename, int nSize);
          

            private static bool Callback(int hWnd, int lparam) {
                int processId;
                StringBuilder sb1 = new StringBuilder(1024);
                StringBuilder sb2 = new StringBuilder(1024);

                int getIdResult         = GetWindowThreadProcessId((IntPtr)hWnd, out processId);
                int getWindowTextResult = GetWindowText((IntPtr)hWnd, sb1, 1024);
                int openProcessResult   = OpenProcess((PROCESS_QUERY_INFORMATION+PROCESS_VM_READ), true, processId);
                int getFileNameResult   = GetModuleFileNameEx((IntPtr)openProcessResult, IntPtr.Zero, sb2, 1024);

                _WinStructList.Add(new WinStruct { MainWindowHandle = hWnd, WinTitle = sb1.ToString(), ProcessPath = sb2.ToString(), ProcessId = processId });
                return true;
            }

            public static List<WinStruct> GetWindows() {
                _WinStructList = new List<WinStruct>();
                EnumWindows(callBackPtr, IntPtr.Zero);
                return _WinStructList;
            }
        }
    }
'@
Add-Type -TypeDefinition $GetWindowsDefinition

$windowNames = @(
    '^Prime95 \- Self\-Test$',
    '^Prime95 \- Not running$',
    '^Prime95 \- Waiting for work$',
    '^Prime95$'
)

'Searching for windows with any of these titles:'
$windowNames -Join ', '

$windowObj = [GetWindows.Main]::GetWindows() | Where-Object {
    $_.WinTitle -match ($windowNames -Join '|')
}

''
'All windows found with these titles: '
$windowObj | ForEach-Object {
    $path = (Get-Process -Id $_.ProcessId -ErrorAction Ignore).Path

    '--------------------------------------------------------'
    ' - WinTitle:          ' + $_.WinTitle
    '   ProcessId:         ' + $_.ProcessId
    '   Process Path (C):  ' + $_.ProcessPath
    '   Process Path (PS): ' + $path
    ''
}

''
'Filtering the found windows for the path containing ".*prime95\.exe$" (PS)'
$filteredWindowObjPS = $windowObj | Where-Object {
    (Get-Process -Id $_.ProcessId -ErrorAction Ignore).Path -match '.*prime95\.exe$'
}

''
'Filtered windows:'
$filteredWindowObjPS | ForEach-Object {
    $path = (Get-Process -Id $_.ProcessId -ErrorAction Ignore).Path

    '--------------------------------------------------------'
    ' - WinTitle:          ' + $_.WinTitle
    '   MainWindowHandle:  ' + $_.MainWindowHandle
    '   ProcessId:         ' + $_.ProcessId
    '   Process Path (C):  ' + $_.ProcessPath
    '   Process Path (PS): ' + $path
    ''
}

''
'Filtering the found windows for the path containing ".*prime95\.exe$" (C)'
$filteredWindowObjC = $windowObj | Where-Object {
    $_.ProcessPath -match '.*prime95\.exe$'
}

''
'Filtered windows:'
$filteredWindowObjC | ForEach-Object {
    $path = (Get-Process -Id $_.ProcessId -ErrorAction Ignore).Path

    '--------------------------------------------------------'
    ' - WinTitle:          ' + $_.WinTitle
    '   MainWindowHandle:  ' + $_.MainWindowHandle
    '   ProcessId:         ' + $_.ProcessId
    '   Process Path (C):  ' + $_.ProcessPath
    '   Process Path (PS): ' + $path
    ''
}
 
Searching for windows with any of these titles:
^Prime95 \- Self\-Test$, ^Prime95 \- Not running$, ^Prime95 \- Waiting for work$, ^Prime95$

All windows found with these titles:
--------------------------------------------------------
- WinTitle: Prime95 - Self-Test
ProcessId: 11492
Process Path (C): F:\Tools\CoreCycler-v0.8.0.0-RC3\test_programs\p95\prime95.exe
Process Path (PS): F:\Tools\CoreCycler-v0.8.0.0-RC3\test_programs\p95\prime95.exe


Filtering the found windows for the path containing ".*prime95\.exe$" (PS)

Filtered windows:
--------------------------------------------------------
- WinTitle: Prime95 - Self-Test
MainWindowHandle: 394152
ProcessId: 11492
Process Path (C): F:\Tools\CoreCycler-v0.8.0.0-RC3\test_programs\p95\prime95.exe
Process Path (PS): F:\Tools\CoreCycler-v0.8.0.0-RC3\test_programs\p95\prime95.exe


Filtering the found windows for the path containing ".*prime95\.exe$" (C)

Filtered windows:
--------------------------------------------------------
- WinTitle: Prime95 - Self-Test
MainWindowHandle: 394152
ProcessId: 11492
Process Path (C): F:\Tools\CoreCycler-v0.8.0.0-RC3\test_programs\p95\prime95.exe
Process Path (PS): F:\Tools\CoreCycler-v0.8.0.0-RC3\test_programs\p95\prime95.exe

Das gibt es während die Fehlermeldung im CoreCycler gibt
 
Rodger schrieb:
Das gibt es während die Fehlermeldung im CoreCycler gibt
Jetzt wirds ja ganz wild, das manuell ausgeführte Script erkennt den Pfad auf beide Arten und das CoreCycler-Script nicht. :confused_alt:

Teste mal bitte, ob das angehängte Script im momentanen Entwicklungszustand funktioniert, und wenn nicht, was die Logdatei ausspuckt.
 

Anhänge

  • Gefällt mir
Reaktionen: Rodger
Tadaaaaaaah!
Funzt!

Habe das Script über das im RC3 drübergebügelt und gestartet....LÄUFT! :daumen:

Starting the CoreCycler
--------------------------------------------------------------------------------
------------ CoreCycler v0.8.0.0 RC3 started at 2021-03-29 17:22:06 ------------
--------------------------------------------------------------------------------
Verbose mode is ENABLED: .. Writing to log file
Stress test program: ...... PRIME95
Selected test mode: ....... SSE
Logical/Physical cores: ... 24 logical / 12 physical cores
Hyperthreading / SMT is: .. ON
Selected number of threads: 1
Runtime per core: ......... 6 minutes
Suspend periodically: ..... ENABLED
Test order of cores: ...... DEFAULT (ALTERNATE)
Number of iterations: ..... 10000
Selected FFT size: ........ Huge (8960K - 32768K)
--------------------------------------------------------------------------------
The log files for this run are stored in:
F:\Tools\CoreCycler-v0.8.0.0-RC3\logs\
- CoreCycler: CoreCycler_2021-03-29_17-22-03_PRIME95_SSE.log
- Prime95: Prime95_2021-03-29_17-22-03_SSE_Huge_FFT_8960K-32768K.txt
--------------------------------------------------------------------------------


17:22:09 - Iteration 1
----------------------------------
17:22:09 - Set to Core 0 (CPU 0)
Running for 6 minutes...
 
@sp00n.82
Danke an dich, dass du dich so mit deinem Tool reinhängst, erleichtert das Testen auf Stabilität ungemein. Hut ab dafür.

Habe jetzt über mehrere Nächte mal AVX, AVX2 und dann wieder SSE mit FFT-Size All durchlaufen lassen, weiterhin alles Stabil mit -30 auf allen Kernen.

Wie verfährt der CoreCycler eigentlich bei FFT All? Wird da Random durchgetauscht oder alles sauber der Reihe nach? Und wie lange müsste man das Tool für alle FFT Größe laufen lassen?
 
Razor0012 schrieb:
Wie verfährt der CoreCycler eigentlich bei FFT All? Wird da Random durchgetauscht oder alles sauber der Reihe nach? Und wie lange müsste man das Tool für alle FFT Größe laufen lassen?
CoreCycler ruft dafür ja nur Prime95 auf. Und Prime95 hat da tatsächlich eine Art Zufallsgenerator drin bei größeren FFT-Größen. Den Algorithmus dahinter habe ich allerdings nicht so wirklich verstanden. 😵
Zumindest der erste Durchlauf scheint aber immer in der gleichen Reihenfolge abzulaufen, wenn auch nicht in numerischer Reihenfolge. Danach wird dann irgendwie wild durcheinander gewürfelt, auch mit mehrfachen Wiederholungen.
Dementsprechend variiert dann auch die Zeit, bis alle FFT-Größen mindestens ein Mal drangekommen sind, bei meinen Tests hatte ich folgende Werte bei meinem 5900x und 1 Thread:
# - Prime95 "All": [SSE] ~40-65 Minutes <|> [AVX] ~92-131 Minutes <|> [AVX2] ~102-159 Minutes

Wobei der erste Durchlauf in der Regel einer der schnellsten ist, da es da ja noch nicht so komplett durcheinander ist.
 
Zuletzt bearbeitet:
Frohe Ostern!

Version 0.8.0.0 ist jetzt verfügbar.
Aida64 und Y-Cruncher werden nun unterstützt!


Download:
https://github.com/sp00n/corecycler/releases


Changelog:
  • Prime95 auf Version 30.5 Build 2 upgedatet
  • Aida64 und Y-Cruncher werden jetzt unterstützt! Man kann jetzt festlegen, welches Stresstest-Programm verwendet werden soll (Achtung: lest den entsprechenden Abschnitt zu Aida64 in der readme.txt)
  • Die config.ini wurde restrukturiert, um Aida64 und Y-Cruncher zu unterstützen. Alte Config-Dateien funktionieren nun nicht mehr!
  • Eine Einstellung "suspendPeriodically" hinzugefügt, die standardmäßig aktiv ist. Mit dieser Einstellung wird das Stresstest-Programm in regelmäßigen Abständen pausiert und wieder fortgesetzt, um Lastwechsel zu simulieren
  • Eine Einstellung "coreTestOrder" hinzugefügt, die standardmäßig "Alternate" (für CPUs mit mehr als 8 Kernen/2 CCDs) bzw. "Random" (für max. 8 Kerne/1 CCD) gesetzt ist. Man kann aber auch eine komplett benutzerdefinierte Reihenfolge eingeben, in der die Kerne getestet werden sollen (z.B. "5, 7, 5, 1, 0, 7, 4")
  • Mehrere neue Presets für Prime95 hinzugefügt: "Moderate", "Heavy" & "HeavyShort". In der Config-Datei stehen mehr Infos zu diesen Presets
  • Die Priorität des Stresstest-Programms wird jetzt auf "Hoch" gesetzt, damit ihm andere Prozesse nicht Prozessorzeit "klauen" können, was anderenfalls zu Fehlalarmen bei der Erkennung der Prozessorauslastung führen könnte
  • Der Start eines Stresstest-Programms stiehlt nun nicht mehr den Fokus des gerade offenen Fensters (bzw. gibt ihn sofort wieder zurück)
  • Beim Drücken von STRG+C versucht das Script nun, das laufende Stresstest-Programm ebenfalls zu beenden (sofern es noch CPU-Auslastung verursacht)
  • Der Titel des Fenster wird nun auf "CoreCycler" gesetzt
  • Die ungefähre Prozessorgeschwindigkeit wird nun in den Verbose-Logs ausgegeben (leider ist der Wert nicht so genau wie z.B. HWInfo64 oder Ryzen Master, weswegen er auch nicht in der normalen Ausgabe erscheint)
  • Alle Logdateien landen nun im /logs Ordner, nicht mehr verteilt über mehrere Ordner
  • Im /tools Ordner gibt es nun eine "analyze_prime95_logfile.ps1"-Datei, mit der man ermitteln kann, wie lange Prime95 für einen kompletten Durchlauf aller FFT-Größen gebraucht hat
  • "CoreTunerX" befindet sich nun im /tools Ordner. Mehr Infos zu CoreTuneX und für was es gut ist finden sich hier: https://github.com/CXWorld/CoreTunerX
 
  • Gefällt mir
Reaktionen: fast_Manu, DerBandi und AthlonXP
@sp00n.82

5800x stock settings (cmos):

Kerne 0, 1, 5, 6 spucken mir dies aus:

ERROR: Prime95 seems to have stopped with an error!
ERROR: At Core 5 (CPU 10)
ERROR MESSAGE: FATAL ERROR: Rounding was 0.5, expected less than 0.4
ERROR: The last passed FFT size before the error was: 26880K
ERROR: Unfortunately FFT size fail detection only works for Smallest, Small or Large FFT sizes.

ERROR: Prime95 seems to have stopped with an error!
ERROR: At Core 6 (CPU 12)
ERROR MESSAGE: FATAL ERROR: Rounding was 0.4999992847, expected less than 0.4
ERROR: The last passed FFT size before the error was: 8960K
ERROR: Unfortunately FFT size fail detection only works for Smallest, Small or Large FFT sizes.

....

ist so eine teildeaktivierte 2 CCD CPU

ist die CPU Defekt? oder ein Bug. Verursacht über mehrere Tage auch mit hohen curve optimizer Werten keine restarts oder bluescreens. Bei Games, browsing, oder nur idle windows über nacht.
 
@Ragnador prime95 Fehler gibt es auch bei nicht perfekt stabilem RAM-OC, gerade die hohen FFT Tests von Prime95 gehen durch den RAM. Teste das RAM-OC auch immer noch zusätzlich mit dem prime95 Blendtest.
 
Javeran schrieb:
@Ragnador prime95 Fehler gibt es auch bei nicht perfekt stabilem RAM-OC, gerade die hohen FFT Tests von Prime95 gehen durch den RAM. Teste das RAM-OC auch immer noch zusätzlich mit dem prime95 Blendtest.
Hatte cmos reset settings getestet also mit SPD settings aufm ram. er war aber auch schon bei xmp und bei custom overclock @4000 mit memtest stabil betrieben. auch blender prime lief 24h mit allen 3 settings ohne probs durch.
 
Ragnador schrieb:
ist die CPU Defekt? oder ein Bug. Verursacht über mehrere Tage auch mit hohen curve optimizer Werten keine restarts oder bluescreens. Bei Games, browsing, oder nur idle windows über nacht.
Es gab ein paar wenige Leute, die auch solche Probleme bei Stock-Settings hatten. Bei manchen war nach einem Wechsel der Prime95-Version solche Fehler weg, andere mussten positive Werte beim Curve Optimizer angeben, um ein stabiles Setup zu erreichen (oder haben tatsächlich die CPU umgetauscht).
Bei kompletten Stock-Settings sollte die CPU eigentlich komplett ohne Fehler bei Prime95 laufen, wenn das nicht der Fall ist, würde ich tatsächlich einen Austausch einleiten.
Wenn die Fehler nur beim Einsatz von PBO auftreten, dann sieht das vermutlich anders aus, ich glaube nicht, dass da ein fehlerfreier Betrieb garantiert wird, zumal ja die Garantie auf die CPU an sich sogar offiziell flöten geht bei PBO.

Du könntest also mal versuchen, die Prime95 zu wechseln, prinzipiell sollte jede einigermaßen aktuelle Version von Prime95 funktionieren, wenn man sie in den test_programs\p95 Ordner kopiert.
Mitgeliefert wird zur Zeit 30.5 build 2, die neueste Testversion ist 30.6 build 4, die letzte offizielle Version die 30.3 build 6.
Bei einem absturzfreien Betrieb von Windows kann es übrigens durchaus noch Rundungsfehler bei Prime95 geben, da beim Stresstest explizit auf bekannte Ergebnisse geprüft wird, da machen sich auch kleine Instabilitäten dann irgendwann bemerkbar. Für einen Absturz / Reboot muss es schon ein ziemlich instabiles Setting sein.
 
  • Gefällt mir
Reaktionen: SuperSabo und Ragnador
ok habe mal die Prime ein paar mal ausgetauscht.
Die alte 30.3 beta 6 die ich hatte funktioniert ohne Probleme, die 30.5 und die 30.6 stürzen beim ersten large FFT test in jedem Worker ab.

Mal sehen, ob die alte version mir "stabile" co werte gibt oder einfach alles durchwinkt. Meld mich dann nochmal
-----------------------------------------------------------------------------------------------------------------------
EDIT:


@sp00n.82
Hab ne Antwort bekommen:

"A bug was introduced somewhere in the 30.4/30.5 changes. Your problem is fixed in 30.6 build 4."


Werde es nun mal testen. Vielleicht zur Sicherheit mal dann die verwendete version im corecycler ersetzen.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: SuperSabo und sp00n.82
Ich habe eben Version 0.8.2.0 veröffentlicht.

HINWEIS:
In der bislang mitgelieferten Version von Prime (30.4 bzw. 30.5) gibt es anscheinend einen Bug, der zu falschen Fatal Errors bei Prime95 selbst geführt haben könnte. In der nun mitgelieferten Version 30.6 build 4 soll dieser Fehler laut dem Entwickler nun behoben sein (siehe hier: https://www.mersenneforum.org/showpost.php?p=577388&postcount=274).
Demzufolge sollten alle, die bisher auch bei Stock Settings unerklärliche Fehlermeldungen hatten, auf diese Version wechseln!


https://github.com/sp00n/corecycler/releases


Changelog:
  • Anscheinend gibt es einen Bug in Prime 30.4 & 30.5, der zu falschen Fatal Errors geführt hat. In der nun mitgelieferten Version 30.6 build 4 soll dieser Fehler laut dem Entwickler behoben sein (siehe hier: https://www.mersenneforum.org/showpost.php?p=577388&postcount=274)
  • Beim Beenden des Scripts gibt es nun eine kurze Zusammenfassung
  • Das Script verhindert nun den Wechsel in den Sleep/Hibernate/Standby-Modus des Computers während der Laufzeit
 
Zuletzt bearbeitet:
Mal ein Gedankenspiel für vielleicht einen 2. Testmodus

Instabilitäten werden ja hier mit SSE getestet, ein Kern alleine maximalster boost.
Jetzt Boosten diese Kerne ja nur auf den maximalsten Wert wenn alle anderen ruhen.
Windows schiebt diese dann auftretenden einzel Kern Belastungen ja dann auf die beiden besten Kerne, wenn alle ruhen. Könnte man dann mehr Multicore Energieeinspaarung und Leistung (durch verringerte Temperatur ... da die Curve Werte ja ansteigen würden) erziehlen wenn die Kerne 4-X (der Leistungseinstufung nach) mit avx getestet werden oder mit SSE während ein Kern 1-3 (Leistungseinstufung) unter einer Teillast Last ist.

Ist nur so eine Theorie bis jetzt, da die Leistungskerne 4-X ja niemals auf den maximaltakt Takten wenn man ihnen nicht wie in diesem synthetischen Fall den einzigen laufenden Prozess zuweist.
 
Zuletzt bearbeitet:
Gedanklenspiel anders formuliert.

Den maximalen Takt legt Windows wenn keine Kerne belastet sind nur auf die beiden Besten.
Die restlichen Kerne werden nur genutzt wenn die besten beiden Kerne (#1/1 und #1/2) schon aufgaben abarbeiten.
Deshalb kommt es nie zu der Situation, dass auf den "schlechteren Kernen" der maximalste Takt den diese ausgeführen könnten nie eintritt (wie bei der künstlichen Auslastung des Tests mit SSE operatoren mit "Huge" getestet wird).

also könnte man die besten 3 kerne wie gehabt testen und ab Kern 4 entweder mit einem teilbelasteten kern( #1/1, #1/2, #2/3) [3. bester kern (#2) als puffer] testen oder vielleicht auf AVX wechseln. da diese kerne nie den maximalsten Takt als effektiv Takt nutzen.

Dadurch wären sie theoretisch dann im SSE test instabil, aber stabil im täglichen gebrauch mit höheren curve optimizer Werten würden allgemein höhere allcore taktraten erreicht.


Die Kernbewertung #Zahl kann man in HWinfo ablesen. Ryzen master zeigt die beiden besten Kerne mit goldenem und silbernem Zeichen an.
 
Hm. Ich bin der Auffassung, das ein instabiler Overclock eben instabil ist und bleibt. Das Testprocedere künstlich auf nur bestimmte Aufgabenbereiche einzuschränken, nur damit es dort unter ganz bestimmten Bedingungen stabil bleibt, halte ich persönlich nicht für sinnvoll. 🤔
 
  • Gefällt mir
Reaktionen: Revolvermann01
Zurück
Oben