Das kann ich so 1:1 unterschreiben für meinen 7950X3D 16-Kerner.
Das kotzt mich gerade sowas von an. Du gehst 1 Schritt vor u gefühlt 3 Schritte wieder zurück. Hab jetzt mal alle Cores +4 erhöht u teste morgen weiter...
Gerade mega frustriert. 😭
CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen
- Ersteller sp00n
- Erstellt am
Das kann ich so 1:1 unterschreiben für meinen 7950X3D 16-Kerner.
Das kotzt mich gerade sowas von an. Du gehst 1 Schritt vor u gefühlt 3 Schritte wieder zurück. Hab jetzt mal alle Cores +4 erhöht u teste morgen weiter...
Gerade mega frustriert. 😭
Bread
Experte
Wieso frustriert - das ist die Natur von Stabilitätstests, dass da regelmäßig was crashed. Wird mit der Zeit weniger, und das ist ja erfreulich weil es in die richtige Richtung geht, und kein Rückschlag? 😉
Hab übrigens alles mit der selben Windows Installation / SSD getestet, auch RAM OC tw mit wilden BSODs. Chkdsk und die 3 DISM Befehle richten immer alles, oder einfach InPlace Drüberinstallieren. rennt immer noch wie ein Glöckerl 😉
Hab übrigens alles mit der selben Windows Installation / SSD getestet, auch RAM OC tw mit wilden BSODs. Chkdsk und die 3 DISM Befehle richten immer alles, oder einfach InPlace Drüberinstallieren. rennt immer noch wie ein Glöckerl 😉
sp00n
Enthusiast
Thread Starter
- Mitglied seit
- 04.09.2012
- Beiträge
- 424
Da muss ich mich jetzt wohl selbst korrigieren bzw. ergänzen. Die APIC IDs haben wohl anscheinend tatsächlich Lücken und sind nicht durchlaufend nummeriert.
Das ist mir besonders bei einem Intel-System aufgefallen, wo pro P-Core anscheinend 8 Ids "reserviert" sind und pro E-Core 2.
Und bei meinem 5900X zählt er die APIC IDs auch von 0-11 im ersten CCD und dann wieder von 16-27 für den zweiten CCD, weil die Kerne dazwischen deaktiviert sind. Nur bei einer CPU mit nur einem CCD oder mit Vollbestückung sollten die also durchgehend nummeriert sein.
Und da mich das ganze genervt hat und es anscheinend keine Möglichkeit gibt, das in Powershell auszulesen, habe ich mich mal wieder an C++ probiert (wie immer mehr schlecht als recht). Aber es scheint zu funktionieren, zumindest bei meinen zwei Rechnern. Das will ich dann auch im CoreCycler verwenden, von daher wären ein paar weitere Tester auch gerne gesehen, ob das stimmt, was ich da hingeschrieben habe. 😉
Releases · sp00n/APICID
Console app to display the APIC ID for each core. Contribute to sp00n/APICID development by creating an account on GitHub.
github.com
Das sollte bei einem (normalen) 5900X folgenden Output produzieren:
Code:
Logical CPU 0 - Physical Core 0 - APIC ID 0 - SMT On
Logical CPU 1 - Physical Core 0 - APIC ID 1 - SMT On
Logical CPU 2 - Physical Core 1 - APIC ID 2 - SMT On
Logical CPU 3 - Physical Core 1 - APIC ID 3 - SMT On
Logical CPU 4 - Physical Core 2 - APIC ID 4 - SMT On
Logical CPU 5 - Physical Core 2 - APIC ID 5 - SMT On
Logical CPU 6 - Physical Core 3 - APIC ID 6 - SMT On
Logical CPU 7 - Physical Core 3 - APIC ID 7 - SMT On
Logical CPU 8 - Physical Core 4 - APIC ID 8 - SMT On
Logical CPU 9 - Physical Core 4 - APIC ID 9 - SMT On
Logical CPU 10 - Physical Core 5 - APIC ID 10 - SMT On
Logical CPU 11 - Physical Core 5 - APIC ID 11 - SMT On
Logical CPU 12 - Physical Core 6 - APIC ID 16 - SMT On
Logical CPU 13 - Physical Core 6 - APIC ID 17 - SMT On
Logical CPU 14 - Physical Core 7 - APIC ID 18 - SMT On
Logical CPU 15 - Physical Core 7 - APIC ID 19 - SMT On
Logical CPU 16 - Physical Core 8 - APIC ID 20 - SMT On
Logical CPU 17 - Physical Core 8 - APIC ID 21 - SMT On
Logical CPU 18 - Physical Core 9 - APIC ID 22 - SMT On
Logical CPU 19 - Physical Core 9 - APIC ID 23 - SMT On
Logical CPU 20 - Physical Core 10 - APIC ID 24 - SMT On
Logical CPU 21 - Physical Core 10 - APIC ID 25 - SMT On
Logical CPU 22 - Physical Core 11 - APIC ID 26 - SMT On
Logical CPU 23 - Physical Core 11 - APIC ID 27 - SMT OnBei meinem 14900KF sieht das so aus:
Code:
Logical CPU 0 - Physical Core 0 - APIC ID 0 - SMT On
Logical CPU 1 - Physical Core 0 - APIC ID 1 - SMT On
Logical CPU 2 - Physical Core 1 - APIC ID 8 - SMT On
Logical CPU 3 - Physical Core 1 - APIC ID 9 - SMT On
Logical CPU 4 - Physical Core 2 - APIC ID 16 - SMT On
Logical CPU 5 - Physical Core 2 - APIC ID 17 - SMT On
Logical CPU 6 - Physical Core 3 - APIC ID 24 - SMT On
Logical CPU 7 - Physical Core 3 - APIC ID 25 - SMT On
Logical CPU 8 - Physical Core 4 - APIC ID 32 - SMT On
Logical CPU 9 - Physical Core 4 - APIC ID 33 - SMT On
Logical CPU 10 - Physical Core 5 - APIC ID 40 - SMT On
Logical CPU 11 - Physical Core 5 - APIC ID 41 - SMT On
Logical CPU 12 - Physical Core 6 - APIC ID 48 - SMT On
Logical CPU 13 - Physical Core 6 - APIC ID 49 - SMT On
Logical CPU 14 - Physical Core 7 - APIC ID 56 - SMT On
Logical CPU 15 - Physical Core 7 - APIC ID 57 - SMT On
Logical CPU 16 - Physical Core 8 - APIC ID 64 - SMT Off
Logical CPU 17 - Physical Core 9 - APIC ID 66 - SMT Off
Logical CPU 18 - Physical Core 10 - APIC ID 68 - SMT Off
Logical CPU 19 - Physical Core 11 - APIC ID 70 - SMT Off
Logical CPU 20 - Physical Core 12 - APIC ID 72 - SMT Off
Logical CPU 21 - Physical Core 13 - APIC ID 74 - SMT Off
Logical CPU 22 - Physical Core 14 - APIC ID 76 - SMT Off
Logical CPU 23 - Physical Core 15 - APIC ID 78 - SMT Off
Logical CPU 24 - Physical Core 16 - APIC ID 80 - SMT Off
Logical CPU 25 - Physical Core 17 - APIC ID 82 - SMT Off
Logical CPU 26 - Physical Core 18 - APIC ID 84 - SMT Off
Logical CPU 27 - Physical Core 19 - APIC ID 86 - SMT Off
Logical CPU 28 - Physical Core 20 - APIC ID 88 - SMT Off
Logical CPU 29 - Physical Core 21 - APIC ID 90 - SMT Off
Logical CPU 30 - Physical Core 22 - APIC ID 92 - SMT Off
Logical CPU 31 - Physical Core 23 - APIC ID 94 - SMT OffDas ist quasi der gleiche Output wie der Report von CPU-Z, nur stark zusammengefasst.
sp00n
Enthusiast
Thread Starter
- Mitglied seit
- 04.09.2012
- Beiträge
- 424
Ich hab jetzt die alpha1 für Version 0.10.0.0 gepusht.
Die beinhaltet den automatischen Testmodus, der die Curve Optimizer-Werte (oder den Voltage Offset bei Intel) bei einem Fehler automatisch verringert.
Ebenso kann sich das Script jetzt nach einem Reboot von selbst neu starten, den CO/Offset-Wert verringern und bei dem Kern weitermachen, bei dem der Crash aufgetreten ist.
Damit sollte dann z.B. ein Lauf über Nacht deutlich effektiver sein.
Das Neustarten nach einem Reboot funktioniert über einen Scheduled Task beim nächsten Logon des Benutzers, für ein wirkliches "AFK"-Testen müsste man also den Autologon für den aktuellen Benutzer einrichten (siehe hier bzw. hier).
Und wichtig zu beachten ist, dass man das Fenster, in dem das Script läuft, währenddessen nicht einfach so schließen sollte, sondern das Script brav mit CTRL+C beenden sollte. Ansonsten wird der eingefügte Scheduled Task nämlich nicht gelöscht und wird beim nächsten regulären Reboot / Login ausgeführt, auch wenn es gar keinen Crash gab.
Ich hab ein paar Sicherungen eingebaut, die das Verhindern sollen, aber komplett fool-proof geht das leider nicht.
Die ganze Sache benötigt Admin-Rechte, das Script fragt dann auch danach, wenn die entsprechenden Settings gesetzt sind (die haben sich übrigens geändert im Vergleich zur letzten 0.9.7.0 alpha, siehe unten).
Des Weiteren gibt es nun eine neue Option, um WHEA Warnungen aus dem Event Log als tatsächliche Fehler zu werten, sofern die dort gemeldete APIC ID dem gerade getesteten Kern entspricht (tut sie es nicht, wird nur eine Warnmeldung ausgegeben).
Das Teil muss jetzt ziemlich eingehend getestet werden, ich hab da doch einiges umgeschrieben.
github.com
Die relevanten Änderungen in der config.ini, inkl. der Erklärung für die Settings:
Die beinhaltet den automatischen Testmodus, der die Curve Optimizer-Werte (oder den Voltage Offset bei Intel) bei einem Fehler automatisch verringert.
Ebenso kann sich das Script jetzt nach einem Reboot von selbst neu starten, den CO/Offset-Wert verringern und bei dem Kern weitermachen, bei dem der Crash aufgetreten ist.
Damit sollte dann z.B. ein Lauf über Nacht deutlich effektiver sein.
Das Neustarten nach einem Reboot funktioniert über einen Scheduled Task beim nächsten Logon des Benutzers, für ein wirkliches "AFK"-Testen müsste man also den Autologon für den aktuellen Benutzer einrichten (siehe hier bzw. hier).
Und wichtig zu beachten ist, dass man das Fenster, in dem das Script läuft, währenddessen nicht einfach so schließen sollte, sondern das Script brav mit CTRL+C beenden sollte. Ansonsten wird der eingefügte Scheduled Task nämlich nicht gelöscht und wird beim nächsten regulären Reboot / Login ausgeführt, auch wenn es gar keinen Crash gab.
Ich hab ein paar Sicherungen eingebaut, die das Verhindern sollen, aber komplett fool-proof geht das leider nicht.
Die ganze Sache benötigt Admin-Rechte, das Script fragt dann auch danach, wenn die entsprechenden Settings gesetzt sind (die haben sich übrigens geändert im Vergleich zur letzten 0.9.7.0 alpha, siehe unten).
Des Weiteren gibt es nun eine neue Option, um WHEA Warnungen aus dem Event Log als tatsächliche Fehler zu werten, sofern die dort gemeldete APIC ID dem gerade getesteten Kern entspricht (tut sie es nicht, wird nur eine Warnmeldung ausgegeben).
Das Teil muss jetzt ziemlich eingehend getestet werden, ich hab da doch einiges umgeschrieben.
Release v0.10.0.0alpha2 · sp00n/corecycler
Fixed a bug with the detection of the starting values (see #79)
github.com
Die relevanten Änderungen in der config.ini, inkl. der Erklärung für die Settings:
Code:
[General]
# Treat a WHEA Warning Event Log entry as an error
# If this is enabled, a WHEA warning (Event Id 19, "corrected hardware error") will be treated as a "real" error
# The testing on the core will be stopped and continued on the next one
# However only if the APIC ID from the WHEA message matches the core that was currently tested, otherwise
# only a warning will be displayed
#
# Default: 1
treatWheaWarningAsError = 1
[...]
# Settings for the Automatic Test Mode
[AutomaticTestMode]
# Enable the automatic test mode
# If you enable this setting, the script will automatically adjust the Curve Optimizer or voltage offset values
# when an error occurs
#
# For Ryzen CPUs up to Zen 4 (Ryzen 7000), it uses PJVol's "pbotest.exe", which is included in the /tools/pbocli/ directory
# For Intel, it uses "IntelVoltageControl", which allows you to set a voltage offset (also included in the /tools/ directory)
#
# Note that this will only INCREASE the Curve Optimizer / voltage offset values, i.e. it will try to make the settings
# more stable, it will never push the settings more into the negative
# Also note that enabling this setting will require the script to be run with administrator privileges
# And lastly, enabling it will set "skipCoreOnError" to 0 and "stopOnError" to 0 as long as the limit has not been reached
#
# IMPORTANT: This currently does not work for Ryzen 9000 (Zen 5) CPUs
#
# Default: 0
enableAutomaticAdjustment = 0
# The starting Curve Optimizer / voltage offset values
# You can provide the Curve Optimizer / voltage offset starting values here, or let them be automatically detected
# If you specify values here, they will overwrite your currently applied CO / voltage offset settings
# If you leave the value blank or at "Default", it will try to automatically detect your current settings
#
# Use a comma separated list or define a single value that will be applied to all cores
# For Intel, this currently only really supports a single voltage offset that is applied to each core
# For Ryzen, you can define the Curve Optimizer value for each core
#
# Note: For Ryzen, the minimum possible Curve Optimizer value is defined by your CPU (and possibly motherboard)
# -30 is a common minimum value for Curve Optimizer, sometimes even -50
# Note: For Intel, the values are provided in millivolts, so e.g. -130 for an undervolt of -0.130v
#
# IMPORTANT: Use a negative sign if you want negative CO values / a negative voltage offset, not providing a
# negative sign will instead apply a positive CO / voltage offset!
#
# Example for setting Curve Optimizer values for a Ryzen 5800X with 8 cores:
# startValues = -15, -10, -15, -8, 2, -20, 0, -30
#
# Example to assign a single Curve Optimizer value to all cores:
# startValues = -20
#
# Example to assign a voltage offset of -0.120v (120mv) for Intel processors:
# startValues = -120
#
# Default: Default
startValues = Default
# The upper limit for the Curve Optimizer values / voltage offset
# If this limit has been reached, no further adjustments will be performed
# Instead the core will now simply throw an error and the regular "skipCoreOnError" setting will be obeyed
# This is either a Curve Optimizer value or a voltage offset value
#
# IMPORTANT: Be sensible about this value, setting it too high into the positive could apply a too high
# voltage to your CPU and may damage it!
#
# Default: 0
maxValue = 0
# The amount by which to increase the Curve Optimizer / voltage offset value
# On an error, the Curve Optimizer / voltage offset value will be increased by this amount
# For Ryzen, a value between 1 and 5 seems reasonable
# For Intel, you should probably set this to 5 to increase the vCore by 5mv after an error
#
# Setting it to "Default" will set the value to 1 for Ryzen and 5 for Intel
#
# Default: Default
incrementBy = Default
# Repeat the test on a core if it has thrown an error and the Curve Optimizer / voltage offset value was increased
# Setting this to 1 will restart the test, until it has not thrown an error, or until the maximum value has been reached
# Setting it to 0, the script will continue to the next core in line as normal
#
# Default: 1
repeatCoreOnError = 1
# Try to automatically resume after a crash / hard reboot
# If this setting is enabled, the script will try to automatically resume after a reboot has occurred
# It creates a Scheduled Task that will be run at logon, which then tries to resume where it left off,
# optionally repeating the last core with an adjusted value (see the repeatCoreOnError setting)
#
# IMPORTANT: If you just close the CoreCycler window without properly exiting the script with CTRL+C,
# the Scheduled Task will remain and will be executed on the next reboot!
# So make sure that you always exit CoreCycler by pressing CTRL+C
#
# IMPORTANT: The Scheduled Task will execute once you log back in to your user account
# So for a true automated testing, it would be beneficial if you activated auto-logon
# Be aware that this might pose a security risk though, so make sure to consider the risks!
# https://learn.microsoft.com/en-us/sysinternals/downloads/autologon
# https://learn.microsoft.com/en-us/troubleshoot/windows-server/user-profiles-and-logon/turn-on-automatic-logon
#
# Default: 0
enableResumeAfterUnexpectedExit = 0
[/spoiler]
Zuletzt bearbeitet:
Danke für die Mühe, meine Tests stehen leider noch aus :/
Aber eine Frage:
Defaultmäßig rührt das Script nicht in meinen Einstellungen rum, sondern testet nur brav, richtig?
Beim überfliegen der neuen config.ini Einträge sah es so aus, aber bei der Bechreibung von "incrementBy = Default" steht leider nichts dazu.
Hintergrund: Ich möchte das selber anpassen und mit Corecycler nur sicherstellen das alles läuft.
Es sollte in keinster Weise an Einstellungen rumgestellt werden die ich vorgenommen habe.
Aber eine Frage:
Defaultmäßig rührt das Script nicht in meinen Einstellungen rum, sondern testet nur brav, richtig?
Beim überfliegen der neuen config.ini Einträge sah es so aus, aber bei der Bechreibung von "incrementBy = Default" steht leider nichts dazu.
Hintergrund: Ich möchte das selber anpassen und mit Corecycler nur sicherstellen das alles läuft.
Es sollte in keinster Weise an Einstellungen rumgestellt werden die ich vorgenommen habe.
sp00n
Enthusiast
Thread Starter
- Mitglied seit
- 04.09.2012
- Beiträge
- 424
@Zyxx
Ja, standardmäßig testet es nur.
Man muss explizit
Und ich bin jetzt ehrlich gesagt gerade gar nicht sicher, ob die Änderungen überhaupt permanent wären. 😅 Bei einem 5000X3D sind sie es zumindest nicht, die haben aber auch keinen offiziell freigeschalteten Curve Optimizer. Bei meinem momentan ohne CO verwendeten 5900X sind sie auch nicht permanent (und beim Intel-System auch nicht),
Ich denke, das sollte noch als Info bei der Beschreibung der Einstellung dazu, da bräuchte ich also mal ein Feedback, ob die CO Settings bei einem "normalen" Ryzen ins BIOS geschrieben werden oder nur temporär bis zum nächsten Neustart vorhanden sind.
// Edit
In der alpha1 gabs einen Bug mit der richtigen Erkennung der startValues, ist in alpha2 gefixt
github.com
Ja, standardmäßig testet es nur.
Man muss explizit
enableAutomaticAdjustment = 1 in der [AutomaticTestMode] Sektion setzen, damit der Curve Optimizer / voltage Offset angepasst wird.Und ich bin jetzt ehrlich gesagt gerade gar nicht sicher, ob die Änderungen überhaupt permanent wären. 😅 Bei einem 5000X3D sind sie es zumindest nicht, die haben aber auch keinen offiziell freigeschalteten Curve Optimizer. Bei meinem momentan ohne CO verwendeten 5900X sind sie auch nicht permanent (und beim Intel-System auch nicht),
Ich denke, das sollte noch als Info bei der Beschreibung der Einstellung dazu, da bräuchte ich also mal ein Feedback, ob die CO Settings bei einem "normalen" Ryzen ins BIOS geschrieben werden oder nur temporär bis zum nächsten Neustart vorhanden sind.
// Edit
In der alpha1 gabs einen Bug mit der richtigen Erkennung der startValues, ist in alpha2 gefixt
Release v0.10.0.0alpha2 · sp00n/corecycler
Fixed a bug with the detection of the starting values (see #79)
github.com
Zuletzt bearbeitet:
Bread
Experte
Änderungen sind nicht permanent, deshalb halte ich die Änderungen für meinen 5800X3D permanent in 2 Powershell Scripts fest, die im Task Scheduler = Aufgabenplanung bei User Logon bzw nach Wakeup ausgeführt werden:
Hab auch andere Anregungen gleich drin gelassen. Zentimings starte ich auch jedes Mal, weil die Kontrolle von tPHYDRL für jedes Modul Sinn macht bei RAM OC. Im Grenzbereich sind die oft asynchron, Kontrolle bei jedem Neustart / WakeUp hilft das aufzudecken und auch die letzten Training-Fehlerchen auszumerzen, Ziel 26/26 sync. Meine RAM Module haben keinen Speicher für Settings, deshalb auch OpenRGB per Script
Das UXTU / Universal x86 Tuning Utility sollte ja auch für per-Core CO mit allen Prozessoren funktionieren inzwischen, hat da schon jemand Erfahrung oder möchte das vor mir ausprobieren? Bittebitte, hab keine Zeit in nächster Zeit
Code:
Invoke-Expression "& 'C:\Users\me\OneDrive\PortableApps\5800X3D\PBO2tuner\PBO2tuner.exe' -30 -30 -24 -30 -27 -30 -30 -30 130 85 130 4550"
Invoke-Expression "& 'C:\Users\me\OneDrive\PortableApps\5800X3D\OpenRGB\OpenRGB.exe' --profile 'Bus'"
Invoke-Expression "& 'C:\Users\me\OneDrive\PortableApps\PortableApps\ZenTimings\ZenTimings.exe'"
# confirm execution of script
Import-Module BurntToast;
$pngPath="C:\Users\me\OneDrive\PortableApps\5800X3D\PBO2tuner\NotifyLogOn.png";
New-BurntToastNotification -Text "Ryzen CO applied!", 'StartUp Script' -AppLogo $pngPath
Code:
Invoke-Expression "& 'C:\Users\me\OneDrive\PortableApps\5800X3D\PBO2tuner\PBO2tuner.exe' -25 -25 -14 -23 -17 -30 -27 -21 130 85 130 4550"
Invoke-Expression "& 'C:\Users\me\OneDrive\PortableApps\5800X3D\OpenRGB\OpenRGB.exe' --profile 'Bus'"
# Stop apps that have issues with being re-started over running instance
Get-Process -Name "ZenTimings" | Stop-Process
# Start
Invoke-Expression "& 'C:\Users\me\OneDrive\PortableApps\PortableApps\ZenTimings\ZenTimings.exe'"
# confirm execution of script
Import-Module BurntToast;
$pngPath="C:\Users\me\OneDrive\PortableApps\5800X3D\PBO2tuner\NotifyWakeUp.png";
New-BurntToastNotification -Text "Ryzen S3UV applied!", 'WakeUp Script' -AppLogo $pngPathHab auch andere Anregungen gleich drin gelassen. Zentimings starte ich auch jedes Mal, weil die Kontrolle von tPHYDRL für jedes Modul Sinn macht bei RAM OC. Im Grenzbereich sind die oft asynchron, Kontrolle bei jedem Neustart / WakeUp hilft das aufzudecken und auch die letzten Training-Fehlerchen auszumerzen, Ziel 26/26 sync. Meine RAM Module haben keinen Speicher für Settings, deshalb auch OpenRGB per Script
Beitrag automatisch zusammengeführt:
Das UXTU / Universal x86 Tuning Utility sollte ja auch für per-Core CO mit allen Prozessoren funktionieren inzwischen, hat da schon jemand Erfahrung oder möchte das vor mir ausprobieren? Bittebitte, hab keine Zeit in nächster Zeit
Zuletzt bearbeitet:
Hallo Zusammen,
ich wusste gar nicht, dass das Tool aus deutscher Hand stammt, Danke für deine Arbeit erstmal!
Bei mir kommt bei jeder Iteration auf Core 0,4,5 folgende Fehlermeldung: "FATAL ERROR: Rounding was 0.5, expected less than 0.4 Hardware failure detected running 10752K FFT size"
Dazu habe ich im FAQ des readme nichts gefunden. Den Fehler würde ich so interpretieren, dass der Kern instabil ist und bei der Berechnung dadurch ein Fehler auftritt, korrekt?
Dadurch bin ich auch auf das neue Update gestoßen und führe jetzt nochmal selbiges mit dem Befehl "enableAutomaticAdjustment = 1" aus.
Ryzen Master schmeißt mir alle Kerne auf -25 und -30 - Keine Ahnung was die unter "Stabil" verstehen
ich wusste gar nicht, dass das Tool aus deutscher Hand stammt, Danke für deine Arbeit erstmal!
Bei mir kommt bei jeder Iteration auf Core 0,4,5 folgende Fehlermeldung: "FATAL ERROR: Rounding was 0.5, expected less than 0.4 Hardware failure detected running 10752K FFT size"
Dazu habe ich im FAQ des readme nichts gefunden. Den Fehler würde ich so interpretieren, dass der Kern instabil ist und bei der Berechnung dadurch ein Fehler auftritt, korrekt?
Dadurch bin ich auch auf das neue Update gestoßen und führe jetzt nochmal selbiges mit dem Befehl "enableAutomaticAdjustment = 1" aus.
Ryzen Master schmeißt mir alle Kerne auf -25 und -30 - Keine Ahnung was die unter "Stabil" verstehen
LuxSkywalker
Enthusiast
das spricht dafür das du mit der Prime Binary testest - ist nicht zu empfehlen. Ändere die Config und nimm yCruncher - dabei kommen dann auch belastbare Werte bei rum
mit Prime unter dem CoreCycler zu testen ist m.e. Zeitverschwendung
Kannst du mir sagen an welcher Stelle im Config das Setting dazu steht?
Hab bis auf das genannte Setting alles auf default gelassen. Arbeitet das Skript dann nicht so wie du sagst?
LuxSkywalker
Enthusiast
ich hab mal noche eine gepackte config.ini angehangen - welche diverse änderungen beinhaltet, diese ist für v0.9.6.2
btw. du solltest den Thread durchaus mal komplett lesen 😉
sp00n
Enthusiast
Thread Starter
- Mitglied seit
- 04.09.2012
- Beiträge
- 424
Ich hatte damals während der Entwicklung beinahe mein komplettes Setup mit Prime95 gemacht, also als Zeitverschwendung würde ich das nicht betiteln. 😉
y-cruncher wirft aber vermutlich schneller die "einfachen" Fehler.
Wie auch immer, der Rounding Error wird direkt von Prime95 erzeugt, ist also ein Problem mit der Hardware. Also entweder instabiler Kern oder eben instabiles RAM. Deswegen sollte man sich immer sicher sein, dass die RAM-Settings stabil laufen, ansonsten dreht man an den falschen Schrauben.
y-cruncher wirft aber vermutlich schneller die "einfachen" Fehler.
Wie auch immer, der Rounding Error wird direkt von Prime95 erzeugt, ist also ein Problem mit der Hardware. Also entweder instabiler Kern oder eben instabiles RAM. Deswegen sollte man sich immer sicher sein, dass die RAM-Settings stabil laufen, ansonsten dreht man an den falschen Schrauben.
Würdest du denn, parallel zum Kollegen darüber, Settings empfehlen, die ich ändern sollte? Wie gesagt, hab alles auf default bis auf das automatische Ändern der CO Offsets. (Das hat übrigens hervorragend funktioniert, aber nach Neustart sind die Änderung wieder weg (Könnte aber auch an Ryzen Master liegen?! ))
Mein RAM sollte bei 3600Mhz + IF 1800Mhz stabil laufen. Da hatte ich Jahrelang keine Probleme mit.
sp00n
Enthusiast
Thread Starter
- Mitglied seit
- 04.09.2012
- Beiträge
- 424
Ja, die Änderungen sind nur temporär, darauf muss ich dann noch irgendwo explizit hinweisen. Die muss man dann entweder ins BIOS übertragen oder per Startscript mit PBO2 Tuner (bzw. dem pbotest) bei jedem Windows-Start neu setzen lassen.
Bezüglich der Einstellungen, im /configs Verzeichnis sind ein paar Beispiele drin.
Bezüglich der Einstellungen, im /configs Verzeichnis sind ein paar Beispiele drin.
LuxSkywalker
Enthusiast
bei meinem AM4 lastet Prime per CoreCycler die enzelnen CPU Kerne nicht ausreichend aus - ähnlich wie "Kizuna" - da kann ich ganz schnell unrealistisch niedrige CO Werte fahren die mir dann später aber ganz schnell um die Ohren fliegen.
Daher teste ich nur noch mit yCuncher Kagari - sonst ist es m.e. Zeitverschwendung wenn ich doch später alles mit fordernden Einstellungen nochmal wiederholen muss 🙃
Würde zur Sicherheit die CO Werte mit 3200 usw testen. Außer du hast den RAM wirklich ausgiebig mit z.b. Karuh bis 8K% getestet.
Hi zusammen,
Melde mich nach zwei wöchiger Abstinenz wegen Urlaub wieder zurück. Mittlerweile ist nur noch ein 12 Stunden u 18 Stunden Test offen, gefolgt von einem endgültigen 24 Stunden Test meines 7950X3D 16-Kerner.
Folgende Frage an die Experten hier hätte ich dann aber noch: Wie ist das wenn ich für meine CPU nach den neuen Curve Optimizer Werten pro Kern bedingt durch meine 360 AIO u guten Temps im BIOS die Limits für PPT, TDC, EDC (hab ein Asus X670 Hero Board) erhöhe durch PBO? Funktioniert das dann oder beißt sich das mit dem Curve Optimizer? Muss ich dann wieder auf Stabilität testen?
Oder ist das alles Schwachsinn um ggf. noch etwas mehr Leistung rauszukizeln?
Gerne wieder eure ehrliche Meinung dazu.
LG Hannes
Melde mich nach zwei wöchiger Abstinenz wegen Urlaub wieder zurück. Mittlerweile ist nur noch ein 12 Stunden u 18 Stunden Test offen, gefolgt von einem endgültigen 24 Stunden Test meines 7950X3D 16-Kerner.
Folgende Frage an die Experten hier hätte ich dann aber noch: Wie ist das wenn ich für meine CPU nach den neuen Curve Optimizer Werten pro Kern bedingt durch meine 360 AIO u guten Temps im BIOS die Limits für PPT, TDC, EDC (hab ein Asus X670 Hero Board) erhöhe durch PBO? Funktioniert das dann oder beißt sich das mit dem Curve Optimizer? Muss ich dann wieder auf Stabilität testen?
Oder ist das alles Schwachsinn um ggf. noch etwas mehr Leistung rauszukizeln?
Gerne wieder eure ehrliche Meinung dazu.
LG Hannes
sp00n
Enthusiast
Thread Starter
- Mitglied seit
- 04.09.2012
- Beiträge
- 424
Mit den Power Settings habe ich mich tatsächlich gar nicht großartig beschäftigt, aber da scheint es nicht unbedingt so zu sein, dass mehr = besser ist, zumindest nicht in allen Fällen.
Hier hat z.B. jemand ein paar Tests gemacht, bei denen mittlere EDC-Werte besser waren als hohe. Ob sich das jetzt auch tatsächlich auf die Single-Core Leistung ausgewirkt hat, ist mir im weiteren Verlauf des Threads allerdings nicht ganz klar geworden.
forums.overclockers.co.uk
Im Prinzip sollten die Werte eigentlich nur für Multi-Core Last Ausschlag gebend sein, weil man die Limits im Single-Core gar nicht erreicht.
An sich ist halt alles temperaturabhängig, je heißer ein Core wird, desto weniger hoch kann er boosten. Wenn man also unlimited Power! in die CPU schickt und die Kühlung dafür nicht ausreicht, dann verliert man unter Umständen sogar Performance.
Hier ist auch nochmal ein Video mit ein paar Charts (ab Minute 22:30), da gibt es auch Unterschiede zwischen zwei getesteten CPUs.
Im Multi-Core spielt dann auch noch Vdroop und die Loadline Calibration (LLC) eine Rolle, die die tatsächlich angelegte Spannung beeinflussen, von daher sollte man sowieso auch noch einen Stabilitätstest unter Volllast machen, um sicherzugehen, dass die CO-Werte auch mit Vdroop noch stabil sind (evtl. muss man dann CO oder LLC anpassen).
Wenn du die AiO erst nach dem Ausloten der CO-Werte eingebaut hast, dann solltest du in jedem Fall neu testen, weil du vermutlich niedrigere Temperaturen und damit höhere Frequenzen erreichst. Und auch, wenn du das Setting für den Boost änderst (+X MHz).
Btw, falls jemand Feedback für die 0.10 Alpha hat, immer her damit.
Hier hat z.B. jemand ein paar Tests gemacht, bei denen mittlere EDC-Werte besser waren als hohe. Ob sich das jetzt auch tatsächlich auf die Single-Core Leistung ausgewirkt hat, ist mir im weiteren Verlauf des Threads allerdings nicht ganz klar geworden.
Performance Impact of EDC on Ryzen CPUs
Seeing in HWiNFO64 that my CPU was hitting 100% of the EDC limit, I thought that clearly the clock speed is being held back, and so I would get better performance by raising the limit. Thus begins the journey. Setting EDC higher than the default 140A didn't have the effect I expected, so I...
forums.overclockers.co.uk
Im Prinzip sollten die Werte eigentlich nur für Multi-Core Last Ausschlag gebend sein, weil man die Limits im Single-Core gar nicht erreicht.
An sich ist halt alles temperaturabhängig, je heißer ein Core wird, desto weniger hoch kann er boosten. Wenn man also unlimited Power! in die CPU schickt und die Kühlung dafür nicht ausreicht, dann verliert man unter Umständen sogar Performance.
Hier ist auch nochmal ein Video mit ein paar Charts (ab Minute 22:30), da gibt es auch Unterschiede zwischen zwei getesteten CPUs.
Im Multi-Core spielt dann auch noch Vdroop und die Loadline Calibration (LLC) eine Rolle, die die tatsächlich angelegte Spannung beeinflussen, von daher sollte man sowieso auch noch einen Stabilitätstest unter Volllast machen, um sicherzugehen, dass die CO-Werte auch mit Vdroop noch stabil sind (evtl. muss man dann CO oder LLC anpassen).
Wenn du die AiO erst nach dem Ausloten der CO-Werte eingebaut hast, dann solltest du in jedem Fall neu testen, weil du vermutlich niedrigere Temperaturen und damit höhere Frequenzen erreichst. Und auch, wenn du das Setting für den Boost änderst (+X MHz).
Btw, falls jemand Feedback für die 0.10 Alpha hat, immer her damit.
@sp00n
Danke dir für die vielen hilfreichen u nützlichen Infos.
Kurz: Wie erwartet doch nicht so einfach wie erwartet das Ganze.
Evtl. lass ich es einfach u warte bis Oktober auf den 9950X3D.
Aber der Zen 5 Launch war ja bis jetzt mehr als Reinfall zu sehen. Da lohnt sich kein Wechsel von Zen 4. Hoffentlich ändert sich das im Oktober.
LG Hannes
Danke dir für die vielen hilfreichen u nützlichen Infos.
Kurz: Wie erwartet doch nicht so einfach wie erwartet das Ganze.
Evtl. lass ich es einfach u warte bis Oktober auf den 9950X3D.
Aber der Zen 5 Launch war ja bis jetzt mehr als Reinfall zu sehen. Da lohnt sich kein Wechsel von Zen 4. Hoffentlich ändert sich das im Oktober.
LG Hannes
Da fällt mir ein, mit SCEWin konnte ich den NVRAM vom BIOS editieren und somit dem 5800X3D permanente CO werte verpassen.
Wenn man es danach als BIOS Profil gespeichert hat, konnte man es auch wieder ohne SCEWin nach einem CMOS Reset laden.
github.com
Ui, da muss ich die tage, wenn ich Zeit habe mal reinschauen, ob ich den Curve Shaper zum Laufen bekomme ^^
Wenn man es danach als BIOS Profil gespeichert hat, konnte man es auch wieder ohne SCEWin nach einem CMOS Reset laden.
Beitrag automatisch zusammengeführt:
GitHub - ab3lkaizen/SCEHUB: SCEWIN binaries and solutions for various error messages
SCEWIN binaries and solutions for various error messages - ab3lkaizen/SCEHUB
github.com
Ui, da muss ich die tage, wenn ich Zeit habe mal reinschauen, ob ich den Curve Shaper zum Laufen bekomme ^^
Zuletzt bearbeitet:
Someone help me use this lol. How do I know how much negative offset I want for each core? I'm using 7950x3d. Or at least where to start and what direction to advance in offsets? Or does anyone have a tutorial video on this? I've been trying to overclock my CPU for a few days now but all I could find is people just sharing what numbers they set up for their overclock but this is obviously different on each CPU so https://9apps.ooo/ I have no idea where to start or what number to aim for on all the other core types? I ended up with -15 negative offset on all cores but the PC is only stable under load. When idle it speeds up a lot and crashes. Thanks in advance and sorry for the unqualified questions.
Zuletzt bearbeitet:
Dann sind -15 CO schon zu viel. Fangst halt einfach mit -10 CO oder noch weniger an.
Hi zusammen,
@Bread @sp00n
Bräuchte nochmals schnell eure Hilfe. Bin mittlerweile durch den 12 Stunden Test mit Breads Config (YCruncher_Old + Kagari + Test Duration 60). 18 Stunden u 24 Stunden Tests kommen noch. Was mir aber bereits aufgefallen ist, sind zwei komplette Reboots (einmal im E-Mail Postfach u vorhin im Diablo IV Einstellungsmenü). D.H. der Rechner ist noch nicht stabil? Richtig?
Wenn jetzt 18 Stunden u 24 Stunden reibungslos durchlaufen, was dann? Alle Kerne, da ich ja den Kern mit zu wenig Spannung nicht mehr ermitteln kann, oder doch, aber wie, um 2 Punkte Plus erhöhen? Also den negativen Offset um +2 erhöhen?
Oder was würdet ihr machen, um das System stabiler zu bekommen?
LG Hannes u Danke für eure Hilfe
@Bread @sp00n
Bräuchte nochmals schnell eure Hilfe. Bin mittlerweile durch den 12 Stunden Test mit Breads Config (YCruncher_Old + Kagari + Test Duration 60). 18 Stunden u 24 Stunden Tests kommen noch. Was mir aber bereits aufgefallen ist, sind zwei komplette Reboots (einmal im E-Mail Postfach u vorhin im Diablo IV Einstellungsmenü). D.H. der Rechner ist noch nicht stabil? Richtig?
Wenn jetzt 18 Stunden u 24 Stunden reibungslos durchlaufen, was dann? Alle Kerne, da ich ja den Kern mit zu wenig Spannung nicht mehr ermitteln kann, oder doch, aber wie, um 2 Punkte Plus erhöhen? Also den negativen Offset um +2 erhöhen?
Oder was würdet ihr machen, um das System stabiler zu bekommen?
LG Hannes u Danke für eure Hilfe
Bread
Experte
Also im Teillast Bereich, ohne Belastung rebootet er? Das klingt nach Power Supply Idle Control = low im BIOS. Setz das mal auf Typical.
Ev auch mal Cool n Quiet = PSS deaktivieren.
RAM ist stabil mit TM5 Test?
Ev auch mal Cool n Quiet = PSS deaktivieren.
RAM ist stabil mit TM5 Test?
Würde ich als Laie sagen: Ja. Die zwei Features gucke ich mir nach der Arbeit mal an, wo ich diese bei meinem Asus X670E Hero im Bios finde.
RAM (64GB, zwei Sticks) habe ich mit 1,4000 V Expo 2 6000 laufen. Sonst nix dran gemacht. Lief vorher immer anstandslos u. keine Reboots in 1,5 Jahren.
Erst durch die Curve Optimizer Änderungen mit den negativen Offsets habe ich jetzt diese Reboots.
Von daher würde ich den RAM ausschließen. Richtige Schlussfolgerung? Wenn Nein, gib mir mal kurz Hilfe, wie ich den RAM genau mit was testen kann.
Zuletzt bearbeitet:
Habe beide Einstellungen soeben im Bios geändert.
Was ist jetzt genau das Vorgehen? Warten und Hoffen, dass nichts mehr passiert ansonsten hier wieder bei dir @Bread melden?
PS: Hab damals noch zwei Settings im Bios geändert, wie ich den 7950X3D bekommen habe.
1. 1,2000 V für VSoC
2. 1,2500 V für VDDIO MC Voltage manuell abgesenkt
Kann das darauf Einfluss haben?
PPS: @Bread
Kannst du mir dennoch mal das Tool + die richtige Config zum RAM testen verlinken oder schicken?
Dann würde ich das mal WE probieren. Kann ja nicht schaden.
LG Hannes
Zuletzt bearbeitet:
seppelchen
Foto-Master of 03/11
24 Stunden Test mache ich schon lange nicht mehr. Auch keine 12 Stunden... 4 Stunden sind das höchste der Gefühle. Wenn mit Prime95, ycruncher, TM5 und beim Gaming alles stabil ist, dann reicht mir das. Reboots hatte ich nach einiger Zeit, da war das CO zu scharf (also zB. Negativ -25, bin dann auf 20) - konnte ich in den Aida CPU Benchmarks reproduzieren. Musste halt jeden Core einzeln testen, zum Glück war es Core 4.
Ich habe seit einigen Tagen VSoc 1,000V eingestellt. Läuft genauso stabil wie 1,175V, jedoch kann sich die CPU dann 2-3W mehr genehmigen. Interessanterweise sind die Ergebnisse in SuperPi mit 1,0 und 1,3V am besten - 1,75V war etwas schlechter.
Ich habe seit einigen Tagen VSoc 1,000V eingestellt. Läuft genauso stabil wie 1,175V, jedoch kann sich die CPU dann 2-3W mehr genehmigen. Interessanterweise sind die Ergebnisse in SuperPi mit 1,0 und 1,3V am besten - 1,75V war etwas schlechter.
Bread
Experte
Ja, wobei ich mit Ryzen 7000 keine Erfahrung habe. Aber teste jetzt mal mit den anderen Settings zuerst.
Definitiv! Hier das neueste TM5: https://github.com/CoolCmd/TestMem5Kannst du mir dennoch mal das Tool + die richtige Config zum RAM testen verlinken oder schicken?
Dann würde ich das mal WE probieren. Kann ja nicht schaden.
Im Programm dann die "Absolut @ anta777.cfg" laden und laufen lassen.
Ähnliche Themen
- Artikel
