CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

[sp00n.82]

Gibt es denn eine "Empfehlung" für die verschiedenen Einstellungen im Hinblick auf Zeitintervalle usw.?

Keine so wirkliche.
Bei den standardmäßigen Small FFT braucht mein 5900X 5,x Minuten für einen Durchlauf, die Standardzeit habe ich also mal auf 6 Minuten pro Kern eingestellt. Damit müsste jeder Kern alle Small FFTs einmal durchmachen können.
Bei langsameren CPUs könnte das aber durchaus etwas länger dauern (Zen2?).
Bei Large FFTs mache ich 20 Minuten pro Kern.

In der von Prime95 generierten results.txt (der Pfad dahin erscheint beim Start des Tools) wird alle paar Minuten ein Zeitstempel geschrieben, daran kann man sich ungefähr orientieren.


@Haldi
Es wird ja nichtmal eine Excel-Datei geschrieben, das war nur ein Beispiel, wie ich mir die Sachen notiert habe (das hatte ich aber auch erwähnt bei dem Bild ).


Bezüglich der Lokalisierung scheine ich eine universelle Lösung gefunden zu haben, ich hoffe es zumindest.

 

[T3mp3sT1187]

Gibt übrigens evtl. noch das Problem, dass die Prozesscounters nicht existieren, das Problem hatte ich auf meinem System, musste diese neu erstellen, jetzt läuft es mit dem Workaround vom Discord... Evtl. kann man da auch einen Fehler einbauen, wenn er die nicht findet

 

[sp00n.82]

Die neue Version, die ich später hochladen wollte, sollte das Problem mit den deutschsprachigen bzw. generell nicht-englischsprachigen Windows-Versionen beheben, ebenso enthält es am Anfang einen Check, ob der Counter überhaupt verfügbar ist. Und die Batch-Datei, die das dann wieder aktivieren sollte ist auch dabei (muss aber manuell ausgeführt werden, will das nicht gleich automatisch starten).

Ergänzung (8. März 2021)

Version 0.7.7 ist jetzt verfügbar:
https://github.com/sp00n/corecycler/releases/tag/v0.7.7

Damit sollten jetzt auch deutschsprachige Windows-Versionen korrekt funktionieren, und die Verfügbarkeit des Process Counters wird vor dem Start abgefragt.
Die Readme habe ich auch um eine "Troubleshooting & FAQ"-Sektion ergänzt, dort wird auch auf die beigefügte "enable_performance_counter.bat" Batch-Datei hingewiesen, die den Performance-Counter wieder aktivieren sollte, wobei ich keine Garantie dafür übernehmen kann, dass das tatsächlich funktioniert.
Im Prinzip macht die Batch Datei nur das, was in den entsprechenden Anleitungen manuell gemacht wird.

Ergänzung (8. März 2021)

Tendenziell müsste ich mir glaube ich mal ein paar Betatester suchen, gibt es Freiwillige? 😃

 

[cm87]

Schau doch einfach auf dem Discord der RAM OC Community nach - immerhin sind die halben Kommentare hier von den Usern aus der Community.

Dann erstellen wir dir da gerne einen eigenen Kanal und wir testen fleißig. Immerhin hat ja auch @Stuoningur dir da einen Input bez. der counter für das deutschprachige Windows gegeben - der ist auch dort vertreten.

Falls du Lust hast, hier eine Einladung: https://discord.gg/NjXRk6N

 

[Stuoningur]

Noch ein Problem von einem User auf dem Discord. Scheinbar braucht der C# Code für den "Window Getter" .NET Framework 3.5, was man nachträglich in den Windows Features aktivieren muss. Vielleicht macht es Sinn dafür einen Check einzubauen und/oder eine Option das Feature zu installieren?

 

[kodix]

Läuft bei mir fehlerfrei. Sehr gutes Tool. Danke @sp00n.82 !

 

[cm87]

@sp00n.82
bei mir läuft die 077er Version nicht

 

[cupidstunt]

Bei mir lief die 0.77 gut, bis Core 3 und 4, die takten nicht mehr hoch, obwohl es laut logs keine Auffälligkeiten gibt.
EDIT: nevermind, hatte einen rounding error übersehen Wusste aber nicht, dass ein Fehler dann zum Abbruch führt, obwohl das tool angeblich weitertestet (aber nicht mehr taktet).

@sp00n.82 möchtest du bug reports lieber auf Github bündeln oder wäre das in dem Thread hier auch ok?

 

[sp00n.82]

@cupidstunt
Das Tool merkt sich die Cores, bei denen ein Fehler aufgetreten ist, und überspringt diese dann beim nächsten Durchlauf. So kann man das länger laufen lassen, z.B. über Nacht, und mehrere Kerne finden, die noch instabil sind. Eigentlich hätte das im Terminal-Fenster und in der Logdatei auch ausgegeben werden müssen.

@cm87
Hmmm. Was passiert, wenn du folgenden Code in einem Powershell-Terminal ausführst?

function Get-PerformanceCounterLocalName {
    param (
        [UInt32]
        $ID,
        $ComputerName = $env:COMPUTERNAME
    )

    $code = '[DllImport("pdh.dll", SetLastError=true, CharSet=CharSet.Unicode)] public static extern UInt32 PdhLookupPerfNameByIndex(string szMachineName, uint dwNameIndex, System.Text.StringBuilder szNameBuffer, ref uint pcchNameBufferSize);'

    $Buffer = New-Object System.Text.StringBuilder(1024)
    [UInt32]$BufferSize = $Buffer.Capacity

    ''
    '-------- Get-PerformanceCounterLocalName --------'
    'ID: '
    $ID

    $t = Add-Type -MemberDefinition $code -PassThru -Name PerfCounter -Namespace Utility
    $rv = $t::PdhLookupPerfNameByIndex($ComputerName, $ID, $Buffer, [Ref]$BufferSize)

   
    ''
    't: '
    $t   

    ''
    'rv: '
    $rv

    if ($rv -eq 0) {
        ''
        'Final Result: '
        $Buffer.ToString().Substring(0, $BufferSize-1)
    }
    else {
        ''
        'COULD NOT GET THE LOCALIZED NAME!'
    }
}

$counterNameIds = @{
    'Process'          = 230         
    'ID Process'       = 784
    '% Processor Time' = 5972
}

Get-PerformanceCounterLocalName $counterNameIds['Process']
Get-PerformanceCounterLocalName $counterNameIds['ID Process']
Get-PerformanceCounterLocalName $counterNameIds['% Processor Time']

 

[Stuoningur]

@cm87
Hmmm. Was passiert, wenn du folgenden Code in einem Powershell-Terminal ausführst?

Haben wir schon "gefixt". Aus irgendwelchen Gründen gab es den Performance Counter gar nicht, schon der 2. user aus dem Discord.

Rebuilding der Counter hat geholfen:
https://docs.microsoft.com/en-us/tr...ormance/manually-rebuild-performance-counters

 

[cm87]

@sp00n.82 hab es bereits gefixt - @Stuoningur hat mir da kurz auf Discord unter die Arme gegriffen.

Hab mich hier durch gearbeitet:
https://docs.microsoft.com/en-us/tr...ormance/manually-rebuild-performance-counters

Performance Logs and Alerts waren bei mir nicht mal gestartet...
Naja... Jetzt läuft es - Danke

Ergänzung (8. März 2021)

Liegt aber nicht an dem von mir genannten Dienst...

 

[sp00n.82]

@cm87
Dafür hatte ich auch die Batch-Datei im /troubleshoot Ordner hinzugefügt.
Eigentlich hätte bei dem Fehler ein Hinweis auf den Eintrag in der Readme angezeigt werden sollen, bei dir ist er aber vorher schon rausgesprungen. 🤨

Ergänzung (8. März 2021)

Btw, der Performance Logs and Alerts Service scheint auch gar nicht benötigt zu werden, bei mir ist er zumindest auch nicht aktiv.
// Edit
Doch nicht, die Meldung käme erst später, wenn der lokalisierte Name herausgefunden werden konnte. Dann füge ich das da auch noch ein.

Ergänzung (8. März 2021)

Version 0.7.8.1 ist jetzt online, sie beinhaltet die Prüfung auf die .NET-Version (explizit 3.5 war übrigens gar nicht notwendig, das war eine unnötige Beschränkung, 4.x scheint auch zu gehen, nur drunter sollte es nicht sein) und die bessere Fehlermeldung bei dem Problem von @cm87 (hoffe ich, das ist blöd zu testen).

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

 

[S.V.K.]

@sp00n.82

Ich danke dir! Das ist genau die Art von Test, die es gebraucht hat, um den CO austesten zu können.
Foxel hat gute Vorarbeit geleistet, er konnte aber die Gründe für das Verhalten des CO nicht erklären und hatte auch leider keine gute Idee, wie man die Stbilität korrekt prüfen kann.
Dieses Lob genührt dir und ich finde es klasse. Vielen vielen Dank dafür!
Für die Mühe und auch für die Tatsache, dass du dein Tool mit uns teilst.

 

[--Q--]

Erstmal danke für das Tool.
Ich nehme an es ist nicht beabsichtigt, dass das Skript weiterläuft und Cores switch, während Prime95 bereits ausgestiegen ist?

Welche Infos brauchst du, falls du das untersuchen möchtest?

 

[sp00n.82]

Ich nehme an es ist nicht beabsichtigt, dass das Skript weiterläuft und Cores switch, während Prime95 bereits ausgestiegen ist?

Doch, eigentlich sollte Prime95 dann automatisch neu gestartet werden und mit dem nächsten Core weitertesten. Der Core mit dem Fehler wird dann intern gepeichert und beim nächsten Durchlauf mit einer entsprechenden Meldung übersprungen, damit man mehrere Kerne in einem "Rutsch" durchtesten kann, also z.B. über Nacht.
Ich könnte aber auch noch eine "StopOnError" Konfigurations-Einstellung hinzufügen.

 

[--Q--]

Sorry, ungenau ausgedrückt.
Ich meine das Skript läuft weiter und tut so, als ob alles ok wäre, als ob Prime noch am testen wäre. Dabei hat Prime schon einen Fehler geworfen.

 

[Verangry]

Liegt an der Test Dauer, es wird 6 Minuten je Kern gewartet, dann der nächste gestartet. Wenn dabei ein Fehler auftaucht sollte das im Script gemeldet werden.

 

[wegdra]

@--Q-- ändere mal in der Config auf restartPrimeForEachCore = 1

 

[sp00n.82]

Liegt an der Test Dauer, es wird 6 Minuten je Kern gewartet, dann der nächste gestartet. Wenn dabei ein Fehler auftaucht sollte das im Script gemeldet werden.

Es wird alle 30 Sekunden nach der Prozessorlast geschaut, man muss als nicht die volle Laufzeit warten.

@--Q--
Hast du zufällig auch bei Github ein Issue eröffnet? Wenn nein, dann wärst du der zweite mit diesem Problem, dass ein Fehler von Prime nicht im Terminal ausgegeben wird. 🤔

 

[--Q--]

Nein, das war ich nicht.
Das mit der Restartoption teste ich später mal.