CoreCycler - Tool zum Testen der Curve Optimizer Einstellungen

[Bread]

Servus @sp00n, der neue CC wirft mir diesen Fehler, das war beim 0.9.4.2 nicht der Fall:

Scheint egal zu sein weil laufen tut der Test dennoch - is aber hässlich

Spoiler: Hat sich erledigt

And it does seem to "Restart for each core", auch wenn das Disabled ist.
Update: nein, das Problem ist offenbar ein anderes. Das Test-Window hat einmal neu gestartet, und bleibt beim N63 hängen, sprich wechselt nicht auf VT3.

Update: mit Admin Rechten läufts. Hatte natürlich beim ersten Mal mit Admin Rechten gestartet, dann erst mit Benutzerrechten, da gabs dann den Hänger.

Update: hat sich erledigt, läuft (warum auch immer) jetzt auch mit Benutzerrechten wie es soll.

 

[LuxSkywalker]

@Bread

@sp00n hatte mit 0.9.5.0 eine fehlerhafte Version released - bitte die aktuelle 0.9.5.2 installieren, damit ist der Fehler mit Adminrechten behoben

 

[Bread]

Early Adopter Schicksale - aber ich fühl mich jetzt wie ein Held an der Release-Front
Meine erste Release auf GitHub hab ich übrigens auch gerade erst zurückgezogen, weil doch noch dies und jenes. Hatte aber glaub ich erst 1 Kunden - mich Btw wenn jemand Interesse an THE RTSS Overlay hat, ich glaub ich habs geschafft

Edit: neue Version läuft "wie ein Glöckerl" - danke!

 

[sp00n]

Der Fehler oben und der mit den Adminrechten waren übrigens zwei Paar Schuhe.
Das ist halt das Problem, wenn man das Testen alles alleine macht, dann seid ihr die Betatester, so wie bei Windows oder aktuellen Games halt. 😁

Beitrag automatisch zusammengeführt: 07.07.2024

Und dann poste ich das auch nochmal hier, ich hab testweise mal Linpack Xtreme integriert (und das nicht gleich als finale Version rausgeschmissen 🤪):

Wer sich das ansehen möchte:

https://github.com/sp00n/corecycler/archive/refs/heads/linpack.zip

Und weil ich den ganzen Text nicht nochmal schreiben möchte, hier die englische Beschreibung:

You can enable it by setting stressTestProgram = LINPACKXTREME

And in the [LinpackXtreme] section you can choose between various modes: SLOWEST, SLOW, MEDIUM, FAST & FASTEST
These modes define which instruction sets are being used by Linpack, FASTEST should be AVX2, FAST should be AVX, and the rest something else, probably SSE (resp. newer or older ones, like SSE2, SSE3, FMA3).
It's not entirely clear which instructions are used exactly, since Linpack Xtreme uses Intel's MKL library, which was not designed for AMD processors, and so you have to use an undocumented debug setting (the MKL_DEBUG_CPU_TYPE environment variable), for which only the 4 and 5 value are known what they're doing (they enable the usage of AVX and AVX2 respectively). At least I think so, as mentioned, this setting is undocumented. But I noticed that values lower than 4 also change the GFlops and testing time, so I assume they use different older instructions.
The setting defaults to MEDIUM (so neither AVX nor AVX2).

You can also choose how much memory to test, it's defaulting to 2GB, which is the lowest value you can choose in the standalone version of Linpack Xtreme.
The amount of memory directly influences how long one test takes, the 2GB took around 100 seconds with MEDIUM (and 40 on FASTEST) for me, while 30GB already ran over an hour before I aborted.

 

[sp00n]

Ich spiele gerade mit dem Gedanken, verschiedene Configs direkt mitzuliefern, also z.B. sowas wie "quick initial test.ini", "overnight.ini", "final long term stability.ini", usw.
Die würde man dann einfach in config.ini umbenennen / dahin kopieren, damit könnte man recht schnell zwischen verschiedenen Konfigurationen hin- und herwechseln.

Bin für Vorschläge hinsichtlich der Konfigs offen.

 

[Vista]

ich würden sagen, schick ein testbuild raus, und wir schauen uns das mal an

 

[sp00n]

Ich hatte mir das jetzt so überlegt, dass es einen neuen Eintrag in der config.ini gibt, bei dem man eine weitere Datei angeben kann, die dann den alle weiteren Werte bestimmt.
D.h. praktisch bräuchte man nur noch diesen einen Eintrag in der config.ini ändern, um zwischen verschiedenen Konfigurationen hin- und herzuwechseln. Das sollte schneller gehen als die Dateien immer umzubenennen.
Das sähe dann so aus:

# General settings
[General]

# The config file to use
# If this value is set, it will use the content from the file provided and all other settings below are ignored
# It's useful for quickly switching between various configs
# You can find some predefined config files in the "configs" directory
# The setting uses a relative path from the location where this file is located in
# Example:
# useConfigFile = configs\quick-initial-test.yCruncher.config.ini
#
# Default: (empty)
useConfigFile =


[...]
Der Rest der Config geht erstmal so weiter wie gehabt, könnte dann aber entfernt werden,
wenn useConfigFile benutzt wird

Und hier sind jetzt ein paar Configs, die ich mir aus dem Ärmel geschüttelt habe (plus die von @Bread, etwas modifiziert).
Im Prinzip würde ich auch gerne eine kleine Zusammenfassung für jede Config haben, für was die eingesetzt werden könnte.


quick-initial-test.yCruncher.config.ini

# This file can be used for an initial test and should find immediate errors rather quickly
# It uses y-Cruncher with 19-ZN2 ~ Kagari and loads it with two threads
# Author: sp00n

[General]
stressTestProgram = YCRUNCHER
runtimePerCore = auto
suspendPeriodically = 1
coreTestOrder = Default
skipCoreOnError = 1
numberOfThreads = 2
restartTestProgramForEachCore = 1
delayBetweenCores = 5

[yCruncher]
mode = 19-ZN2 ~ Kagari
tests = BKT, BBP, SFT, SNT, SVT, FFT, N63, VT3
testDuration = 20

long-final-test.Prime95.config.ini

# This will test ALL available FFT sizes with Prime95 for each core
# It will take a very long time, so it's best to use only after you're pretty sure that you've dialed in your settings
# Author: sp00n

[General]
stressTestProgram = PRIME95
runtimePerCore = auto
suspendPeriodically = 1
coreTestOrder = Default
skipCoreOnError = 1
numberOfThreads = 1

[Prime95]
mode = SSE
FFTSize = All

low-load-scenario.Prime95.config.ini

# This config uses a low-load scenario using Prime95 and is useful for finding possible crashes during load changes
# It uses Prime95 with the SSE instruction set and Huge FFTs
# Author: sp00n

[General]
stressTestProgram = PRIME95
runtimePerCore = auto
suspendPeriodically = 1
coreTestOrder = Default
skipCoreOnError = 1
numberOfThreads = 1
restartTestProgramForEachCore = 1
delayBetweenCores = 15

[Prime95]
mode = SSE
FFTSize = Huge

Prime95.720K.AVX2.config.ini

# Prime95 with 720K FFT size is a popular choice for stress testing CPUs
# Author: sp00n

[General]
stressTestProgram = PRIME95
runtimePerCore = 3m
suspendPeriodically = 1
coreTestOrder = Default
skipCoreOnError = 1
numberOfThreads = 1

[Prime95]
mode = AVX2
FFTSize = 720-720

Prime95.1344K.AVX2.config.ini

# Prime95 with 1344K FFT size is another popular choice for stress testing CPUs
# It was often used to test vCore stability
# Author: sp00n

[General]
stressTestProgram = PRIME95
runtimePerCore = 3m
suspendPeriodically = 1
coreTestOrder = Default
skipCoreOnError = 1
numberOfThreads = 1

[Prime95]
mode = AVX2
FFTSize = 1344-1344

Und die beiden von @Bread:

5800X3D.yCruncher.BreadPit.config.ini

# This config has been determined to be very good for quickly finding errors by the community
# The testing has mainly been done on a 5800X3D processor, but it's also useful for other processors
# Author: BreadPit
# Source: https://www.computerbase.de/forum/threads/corecycler-tool-zum-testen-der-curve-optimizer-einstellungen.2009519/post-29579457

[General]
stressTestProgram = YCRUNCHER
runtimePerCore = auto
coreTestOrder = Sequential
numberOfThreads = 2

[yCruncher]
mode = 19-ZN2 ~ Kagari
tests = N63, VT3
# tests = N63                                       # --> Quick check N63
# tests = N63, VT3                                  # --> Medium check N63 + VT3
# tests = N63, VT3                                  # --> Full Final Check overnight N63 + VT3
# tests = BKT, BBP, SFT, SNT, SVT, FFT, N63, VT3    # --> All tests

5800X3D.yCruncherOld.BreadPit.config.ini

# This config has been determined to be very good for quickly finding errors by the community
# The testing has mainly been done on a 5800X3D processor, but it's also useful for other processors
# This config uses the "old" version of y-Cruncher (v0.7.10), which can produce better results in some cases
# Author: BreadPit
# Source: https://www.computerbase.de/forum/threads/corecycler-tool-zum-testen-der-curve-optimizer-einstellungen.2009519/post-29579457

[General]
stressTestProgram = YCRUNCHER_OLD
runtimePerCore = auto
coreTestOrder = Sequential
numberOfThreads = 2

[yCruncher]
mode = 19-ZN2 ~ Kagari
tests = HNT, VST, C17
# tests = HNT                                           # --> Quick Check HNT only
# tests = HNT, C17                                      # --> Medium HNT + C17 check
# tests = HNT, VST, C17                                 # --> Medium HNT + VST + C17 check
# tests = N64, HNT, VST, C17                            # --> Full Final Check overnight
# tests = BKT, BBP, SFT, FFT, N32, N64, HNT, VST, C17   # --> All tests

 

[Bread]

Find ich super, hilft sicher Neueinsteigern sehr, und auch mir - ev lass ich Prime auch durchlaufen, ggf parallel mit verschobener Core-Reihenfolge.

Den Quick check mach ich immer 30s, das reicht am Anfang um schnell 80/20 auszuloten. In welcher Beziehung steht in dem Zusammenhang RuntimePerCore und TestDuration? Letzteres ist mir neu.

 

[sp00n]

testDuration ist die Dauer für einen einzelnen Test bei y-Cruncher, also BKT, HNT, usw.

Wenn man jetzt nur einen einzigen Test bei y-Cruncher auswählt und runtimePerCore = auto setzt, dann ist die testDuration = runtimePerCore, ansonsten ist es halt testDuration * Anzahl der ausgewählten Tests.

 

[Bread]

Perfekt, danke - macht Sinn, werd ich so übernehmen. Den Parameter gibt's aber erst seit 0.9.5.0 oder?

 

[sp00n]

Hab grad nachsgeschaut, seit 0.9.5.0alpha2.
Von der Versionsnummer nicht so lange her, aber dann doch schon über ein Jahr 😅

 

[Bread]

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?

 

[Scoty]

Kann mir mal bitte einen Crash Kurs geben wie ich am besten mit welchen Settings mein Curve -20 auf alle Kerne bei einen 7800X3D mit 65w ECO testen soll? Es würde mir erst mal reichen wenn der Test schnell ginge. Wenn dieser schnell Test ohne Probleme läuft würde mir das erst mal reichen. Einen ausführlichen Test kann ich ja später immer noch machen. Habe denn CoreCycler v0.9.5.3 mit dem y-cruncher v0.8.5 Build 9541 aktuell.

Wenn ich änderungen in der config.default.ini mache so werden diese nicht übernommen. Habe dort nur Prime durch ycruncher getauscht und dann mal gestartet aber es wurde der Prime Test genommen. Als ich nochmal in die config.default.ini schaute stand auch wieder Prime drin. In der config.ini hingegen wenn ich da Prime durch ycruncher tausche wird es auch übernommen.

Wenn ich starte würde das ganze so aussehen aktuell:

 

[Bread]

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:

Spoiler: config.ini

[General]
# General settings
stressTestProgram = YCRUNCHER_OLD
numberOfThreads = 2

stopOnError = 0
skipCoreOnError = 1
beepOnError = 1
flashOnError = 1
lookForWheaErrors = 1

coreTestOrder = sequential
runtimePerCore = auto
#                                                        # runtimePerCore auto executes all the tests listed in the stressTestProgramgram section with the defined testDuration
suspendPeriodically = 1
#                                                        # Periodically suspend the stress test program to simulate load changes / switches to idle and back
restartTestProgramForEachCore = 0
#                                                        # restartTestProgramForEachCore 0 is default, and leaves the stressTestProgramgram window open so you can scroll thru to double-check for errors
delayBetweenCores = 5
#                                                        # delayBetweenCores 15 is default, 5 simply accelerates the test. If "restartTestProgramForEachCore" is 0, this setting has no effect

[yCruncher]
# y-Cruncher specific settings
mode = 19-ZN2 ~ Kagari
tests = N64, HNT, VST, C17
testDuration = 30
#                                                       # 30 to do a quick check only, 60 is default
# tests = HNT                                            # --> Quick check HNT
# tests = HNT, C17                                        # --> Medium check HNT + C17
# tests = HNT, VST, C17                                    # --> Medium check HNT + VST + C17
# tests = N64, HNT, VST, C17                            # --> Full Final Check overnight
# tests = BKT, BBP, SFT, FFT, N32, N64, HNT, VST, C17    # --> all tests

[Logging]
name = CoreCycler
logLevel = 2
useWindowsEventLog = 1

[Debug]
delayFirstErrorCheck = 5
#                                                        # With this setting you can define a wait time before the first error check happens for each core
stressTestProgramWindowToForeground = 0
#                                                        # 1 throws an error "window cannot be found" in 0.9.4.2

Dauert 2min pro Core.

Wenn es noch kürzer sein soll mit 30s pro Core:
tests = HNT

Voller Check mit 4min pro Core:
testDuration = 60

 

[Scoty]

Danke, übernehme ich mal so.

Edit bekomme einen error, wenn ich das so übernähme:

FATAL ERROR: Der Wert "30 # 30 to do a quick check only, 60 is default" kann nicht in den Typ "System.Int32" konvertiert werden. Fehler: "Die Eingabezeichenfolge hat das falsche Format."
Line Number: 9322

 

[Bread]

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

 

[Zyxx]

Helft mir mal bitte, der Tag war lang und ich finde meine Notizen nicht.
APIC ID 6 laut Windows hat soeben eine Bauchlandung hingelegt mit Hardreset mitten im spielen.

Bei einem 5900X zählt man ab für CCD0 0 bis 5 und von 8 bis 13 bei CCD1. Jetzt stehe ich aufm Schlauch.
Einfach stupide Core 6 im BIOS anheben, wenn von 0 angefangen wird?

 

[Bread]

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:

Spoiler: APIC IDs für 5900X

    -- CCX 0       
        -- Core 0 (ID 0)   
            -- Thread 0    0
            -- Thread 1    1
        -- Core 1 (ID 1)   
            -- Thread 2    2
            -- Thread 3    3
        -- Core 2 (ID 2)
            -- Thread 4    4
            -- Thread 5    5
        -- Core 3 (ID 3)
            -- Thread 6    6
            -- Thread 7    7
        -- Core 4 (ID 4)   
            -- Thread 8    8
            -- Thread 9    9
        -- Core 5 (ID 5)   
            -- Thread 10    10
            -- Thread 11    11
    -- CCX 1       
        -- Core 6 (ID 8)   
            -- Thread 12    16
            -- Thread 13    17
        -- Core 7 (ID 9)
            -- Thread 14    18
            -- Thread 15    19
        -- Core 8 (ID 10)   
            -- Thread 16    20
            -- Thread 17    21
        -- Core 9 (ID 11)   
            -- Thread 18    22
            -- Thread 19    23
        -- Core 10 (ID 12)   
            -- Thread 20    24
            -- Thread 21    25
        -- Core 11 (ID 13)
            -- Thread 22    26
            -- Thread 23    27

 

[sp00n]

APIC ID 6 sollte Core 3 sein. Die APICs zählen die logischen (virtuellen) Kerne, nicht nur die physisch vorhandenen.
Kern 0: APIC 0/1
Kern 1: APIC 2/3
Kern 2: APIC 4/5
Kern 3: APIC 6/7
Kern 4: APIC 8/9
...

Die IDs der physischen Kerne selbst scheinen die von dir beschriebenen Lücken zu haben (weil manche Kerne deaktiviert wurden), aber die Threads = virtuellen = logischen Kerne sollten durchlaufend nummeriert sein.


Es sei denn, du hast SMT im BIOS deaktiviert, dann weiß ichs auch nicht genau. Evtl. mal mit dem Report von CPU-Z gegenchecken.

 

[Scoty]

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

Hat es einen Grund warum denn alten YCRUNCHER_OLD nimmst statt den neueren? Läuft und sieht jetzt so aus:

 

[Zyxx]

@sp00n @Bread danke euch.

Nach vielen Stunden ohne Schlaf habe ich den PC dann erstmal ausgemacht und werde mich dem heute nach Feierabend widmen.
Jetzt wo ihr es sagt... klar.

Aber wie gesagt, zu wenig schlaf die letzten Tage.
Die Liste von CPU-Z (identisch zu Breads) war da mit ausschlaggebend zur Verwirrung, weswegen ich erst einmal beschlossen habe hier um Beistand zu bitten und ersteinmal zu schlafen^^.
Ich werde berichten.

 

[Bread]

Hat es einen Grund warum denn alten YCRUNCHER_OLD nimmst statt den neueren? Läuft und sieht jetzt so aus:

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, haben auch ein paar CB Kollegen getestet, die können mit den neuen Tests tw -6 CO weniger fahren. Bei mir war ja ausgerechnet HNT der Test, der idR den Rechner in die Knie bzw zum Reset gezwungen hat, bei @MehlstaubtheCat @Creekgroundund @Fas7play waren es N64 oder VST / C17. Deshalb hab ich jetzt 2 Varianten

• die alte Konfig übertragen auf die neue CoreCycler Version mittels YCRUNCHER_OLD, mit HNT, N64, VST, C17
• die neue Konfig mit N63 und VT3, was den Prozess vereinfacht / verkürzt, die aber weniger fordernd sind siehe zB hier

 

[hanneslan]

Hi zusammen,

bräuchte mal als blutiger Anfänger euer Schwarm- u. Expertenwissen.

Habe einen 7950X3D u die Config oben von bread YCruncher_Old +Kagari für den Anfang bzw. den Start verwendet.

Ein paar Fragen:

1. Bedeutet ein Neustart bei Iteration 4 u. Core 9, dass nur dieser Core das Problem für den Neustart ist?

2. Oder macht es Sinn gleich alle Cores von -12 um z.B. -2 zu senken? s. Bild

3. Wie würdet ihr hier weitermachen?

4. Auch auffällig, dass es gleich beim Core nebenan des Core 8 Probleme gibt oder?

5. Oder ist das reiner Zufall?

6. Was ist schlimmer ein WHEA Error oder kompletter Neustart des Rechners?

Danke für eure Antworten.

 

[Bread]

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.

 

[sp00n]

6. Was ist schlimmer ein WHEA Error oder kompletter Neustart des Rechners?

Wenn du den WHEA-Error live miterleben kannst, dann war ein "correctable" Error. Bei einem "uncorrectable" Error stürzt dir halt der Rechner ab, von daher ist ein Neustart natürlich schlechter.
Aber auch ein korrigierbarer WHEA-Fehler sollte nicht ignoriert werden, weil es eben ein Hinweis darauf ist, dass das System haarscharf an einem Absturz vorbei geschrammt ist.

 

[hanneslan]

Danke Bread u sp00n für euren Input.

Deine Anleitung in deiner Signatur Bread übersteigt leider mein aktuelles Wissen um mehrere Welten. Da bin ich ganz ehrlich.

Werde mich erstmal von unten in vierer Schritten -4, -8, -12, -16... nach oben testen. Habe mal als Quick-Test nur fünf Iterationen als Anhaltspunkt fest eingestellt u. gewählt. Möchte auch nicht das letzte Quäntchen rausholen, sondern mich vorsichtig nach oben testen.

Spricht da von eurer Seite aus was dagegen außer viel Geduld u viel viel Zeit...?

Oder hat noch jemand Tipps für mich, die relativ einfach umzusetzen sind?

LG Hannes

 

[Bread]

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 -15. Test laufen lassen bis ein Core Fehler wirft. Den +1, alle anderen -1 bis die auch Fehler werfen. Wenn Du dann auf Nummer sicher gehen willst, vom letzten fehlerfreien Run (min 12h) dann +2 bis +5 rauf. Ich hab +0 gemacht, weil dafür teste ich ja

 

[hanneslan]

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 -15. Test laufen lassen bis ein Core Fehler wirft. Den +1, alle anderen -1 bis die auch Fehler werfen. Wenn Du dann auf Nummer sicher gehen willst, vom letzten fehlerfreien Run (min 12h) dann +2 bis +5 rauf. Ich hab +0 gemacht, weil dafür teste ich ja

Ja da hast du natürlich Recht. Ziel soll / muss sein, dass alle 16 Kerne crashen. Core 8+9 habe ich schon durch. Also noch 14 zu gehen.

Hab ganz am Anfang mal AllCore -18 u. AllCore -12 für mehrere Tage am laufen gehabt. Aber nach 2-3 Reboots unkontrolliert unter tlw. nicht Load, war das dann doch nicht 100% stabil u ich bin zurück auf AllCore -8.

Aber auch da steigt Core 8 ja nachgewiesen im Stresstest aus.

Schon interessant das Ganze Testing für einen Neuling. Mach dann mal mit -16 für die restlichen Kerne u 5 Wiederholungen weiter.

Hilfe: Kann ich deine Config Bread zu umschreiben, dass ich nur noch die nicht finalen Kerne teste?

Also alle außer Core 8 u. 9. Macht das Sinn? Wie geht das denn? Kannst du mir ggf. die Code-Zeile dafür posten?

Frage: Kann sich die CPU wenn ich das über mehrere Wochen mache degradieren bzw. abnutzen? Stromverbrauch hält sich ja bei AMD in Grenzen.

LG Hannes

 

[Bread]

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, degradiert, oder auch etwas andere Belastungen durch neue AGESA.

 

[pwnbert]

Gibts das Zeug eigenlich auch auf Linux?

Hab vor paar Monaten mal rumgesucht, aber nix gefunden.
Ist jetzt nicht so wild, hab mir einen Win10 Mobile-OS-Stick gemacht, läuft mit dem brauchbar (obwohl der Stick irgendwie zu klein für ein nacktes Windows wird, sobald das einmal Internet hatte ).