How-To CPU-Stabilitätstest: Software-Kompilierung unter Linux

[ShirKhan]

Noch ein Stabitest. Warum?​

Weil Software-Kompilierung schnell und zuverlässig instabile Hardware-Settings aufdecken kann, die in gängigen Benchmarks und Stabilitätstests unentdeckt bleiben.​

Wer so was noch nicht gemacht hat: kein Problem, dies ist eine Schritt-für-Schritt-Anleitung. Lediglich eine Linux-Installation wird vorausgesetzt.

Spoiler: FAQ

Funktioniert der Test?
Ja, erste Ergebnisse sind vielversprechend. Bei zwei von vier CPUs dreier R.B.R.T.-Mitglieder erkannte er zuvor unbemerktes falsches Overclocking.

Was geschieht beim Kompilieren?
Quellcode wird in ausführbaren Maschinencode übersetzt. Der Vorgang ist rechenintensiv und erfolgt in maximaler Parallelisierung: Alle CPU-Kerne und -Threads werden genutzt, und zwar für reale Rechenaufgaben. Auch der Hauptspeicher wird stark beansprucht.

Warum unter Linux?
Zufall. Der Test entstand als Nebenprodukt während der Entwicklung eines gepatchten Linux-Kernels. Wiederholte Build-Abbrüche entlarvten eine zuvor unkritisch erscheinende CPU-Übertaktung als Fehlerquelle. Daraus entwickelte sich dieser reproduzierbare kleine Stabilitätstest.

Ist das gefährlich?
Die CPU-Auslastung liegt während der Kompilierung meist bei 100 %, die RAM-Belegung kann über 20 GiB steigen. Die dynamisch wechselnde Last führt tendenziell zu geringerer Leistungsaufnahme und etwas niedrigeren Temperaturen als bei synthetischen Stresstests – ist aber dennoch hoch.

Ersetzt der Test Cinebench, OCCT & Co.?
Er kann sie ergänzen. Offensichtlicher Unterschied: Statt unter synthetischer Dauerlast zu schwitzen, dürfen die Komponenten wirklichkeitsnahe, harte Arbeit bei minimaler Fehlertoleranz verrichten. Die Testdauer ist angenehm kurz.

Deckt der Test auch RAM-Instabilität auf?
Im Prinzip ja, denn auch der Speicher wird beim Kompilieren hart gefordert. Um dediziert auf den RAM zu zielen, sollte der Test aber angepasst werden, etwa auf maximale Speicherbelegung minus Systemreserven. Entsprechende Forschung steht noch aus.

Kann der Test als Benchmark genutzt werden?
Ja, auch wenn das weiterer Verifizierung durch eure Rückmeldungen bedarf. Nach erfolgreichem Abschluss des Builds zeigt die Konsole die benötigte Zeit an. Weniger ist besser.

Hinweise​

• Gesamtdauer des ersten Tests inklusive Vorbereitung und einmaligem Software-Download 30–60 Minuten, anschließende Netto-Testzeit je Durchlauf: fünf bis fünfzehn Minuten auf modernen Desktop-Systemen.
• Gebaut, jedoch nicht installiert wird die Software-Sammlung LLVM. Dafür wird einmalig die Kompilierungsumgebung sowie das LLVM-Git-Repository heruntergeladen, Download-Größe: bis zu 2,5 GiB. 15–20 GiB freier Speicherplatz sollten im Home-Verzeichnis zur Verfügung stehen, ggf. prüfen mit df -h ~.
• Die CPU-Last liegt während des Builds meist bei 100 %, die Speicherbelegung steigt auf 15 bis über 20 GiB. Ausreichende RAM-Ausstattung (32 GiB) wird vorausgesetzt.

Tipps: Nicht als root bauen! Den ersten Durchlauf ohne CPU- und RAM-Übertaktung durchführen, um mögliche Fehlerquellen zu isolieren! Ein Monitoring von CPU und RAM während des Tests wird empfohlen.

Durchführung​

1. Kompilierungsumgebung einrichten

(Nach Abschluss des Projekts kann das System in den ursprünglichen Zustand zurückversetzt werden. Hinweise dazu finden sich am Ende dieses How-Tos. Vor Testbeginn bereits vorhandene Pakete sollten nicht ohne Grund entfernt werden. Achtet bei Ausführung der folgenden Installationsbefehle deshalb darauf, welche Pakete tatsächlich neu sind und bei welchen lediglich eine Reinstallation angezeigt wird.)

a) Fedora (für die Testentwicklung eingesetzt), Nobara, Bazzite (im Toolbox-Container), RHEL

sudo dnf install git
sudo dnf install cmake
sudo dnf install make
sudo dnf install gcc
sudo dnf install gcc-c++
sudo dnf install python3

b) Arch Linux, Manjaro, CachyOS, EndeavourOS, Garuda Linux

sudo pacman -S git
sudo pacman -S cmake
sudo pacman -S make
sudo pacman -S gcc
sudo pacman -S python

​

Spoiler: Weitere Distributionen, nicht getestet

c) Debian, Ubuntu, Linux Mint, elementary OS, KDE neon, Knoppix, MX Linux, Pop!_OS, Zorin OS

sudo apt install git
sudo apt install cmake
sudo apt install make
sudo apt install gcc
sudo apt install g++
sudo apt install python3

d) openSUSE (Leap, Tumbleweed)

sudo zypper install git
sudo zypper install cmake
sudo zypper install make
sudo zypper install gcc
sudo zypper install gcc-c++
sudo zypper install python3

e) Gentoo

sudo urpmi git
sudo emerge --ask dev-vcs/git
sudo emerge --ask dev-util/cmake
sudo emerge --ask sys-devel/make
sudo emerge --ask sys-devel/gcc
sudo emerge --ask dev-lang/python

Achtung: Nicht genannte Distros können andere Paketnamen und -manager verwenden. Benötigt werden: git, cmake, make, gcc, g++ (oder ein anderer C++-Compiler), python3

2. LLVM-Quellen herunterladen (ca. 2,2 GB, nur einmal nötig), Build-Verzeichnis anlegen

git clone https://github.com/llvm/llvm-project.git
cd llvm-project
mkdir build
cd build

3. Build-System vorbereiten

cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release ../llvm

4. Stresstest: Kompilierung starten (je nach System ca. 5–15 min)

time make -j$(nproc) 2>/dev/null

Ein erfolgreicher Build endet mit 100 %. Die benötigte Kompilierungszeit wird nach Abschluss angezeigt. Somit ist der Test prinzipiell auch als vergleichender Benchmark geeignet. Soll die Testdauer nach erfolgreichem Abschluss verlängert werden, einfach erneut ausführen.

Erfolgreicher Test in 6:41 min

Ein kleinerer Wert als 100 % bedeutet, der Build wurde abgebrochen. Dies ist ein starker Hinweis auf Hardware-Instabilität. Fehlermeldungen werden durch den Befehlszusatz 2>/dev/null unterdrückt (im Build-Befehl oben enthalten). Ist das nicht gewünscht, bitte nur time make -j$(nproc) verwenden. Abbrüche erzeugen dann meist die Ausgabe „Fehler 2"/"Error 2“, die vermutete Ursache steht innerhalb der letzten 30 Zeilen.


Abbruch aufgrund Hardware-Instabilität (mit aktivierter Fehlerausgabe)

In seltenen, gravierenden Fällen friert das System statt eines Build-Abbruchs ein. Nach dem Reboot auf Meldungen zu initramfs (initial RAM file system) prüfen, nötigenfalls reparieren.


5. Aufräumen vor der Testwiederholung: alten LLVM-Build entfernen (Download bleibt erhalten)

cd ~/llvm-project
rm -rf build

6. Ab dem zweiten Durchlauf können die Befehle kombiniert werden. Copy & Paste + [Enter] startet die Kompilierung sofort.

cd ~/llvm-project
rm -rf build
mkdir build
cd build
cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Release ../llvm
time make -j$(nproc) 2>/dev/null

Für mehrfache Testwiederholung genügt es, Schritt 6. zu wiederholen.


7. Nach Abschluss der Tests: vollständiges Aufräumen von Build und LLVM-Download

cd ~
rm -rf ~/llvm-project

8. Nach Projektabschluss: auf Wunsch Kompilierungsumgebung entfernen

Soll das System nach Projektabschluss in den Ursprungszustand versetzt werden, können die unter 1. zusätzlich installierten Pakete wieder entfernt werden, sofern nicht interne Abhängigkeiten das verhindern. Tipp: Im Zweifel alles installiert lassen, der Platzbedarf ist gering. python/python3 bitte nicht entfernen!

Spoiler: Optionales Entfernen von Paketen der Kompilierungsumgebung

a) Fedora, Nobara, Bazzite (im Toolbox-Container), RHEL

sudo dnf remove git
sudo dnf remove cmake
sudo dnf remove make
sudo dnf remove gcc
sudo dnf remove gcc-c++

b) Arch Linux, Manjaro, CachyOS, EndeavourOS, Garuda Linux

sudo pacman -Rs git
sudo pacman -Rs cmake
sudo pacman -Rs make
sudo pacman -Rs gcc

c) Debian, Ubuntu, Linux Mint, elementary OS, KDE neon, Knoppix, MX Linux, Pop!_OS, Zorin OS

sudo apt remove git
sudo apt remove cmake
sudo apt remove make
sudo apt remove gcc
sudo apt remove g++

d) openSUSE (Leap, Tumbleweed)

sudo zypper remove git
sudo zypper remove cmake
sudo zypper remove make
sudo zypper remove gcc
sudo zypper remove gcc-c++

e) Gentoo

sudo emerge --ask --depclean dev-vcs/git
sudo emerge --ask --depclean dev-util/cmake
sudo emerge --ask --depclean sys-devel/make
sudo emerge --ask --depclean sys-devel/gcc

Achtung: Nicht genannte Distros können andere Paketnamen und -manager verwenden. Zu entfernen, sofern gewünscht: git, cmake, make, gcc, g++ (oder ein anderer C++-Compiler). python/python3 bleibt installiert.

Alles auf eigene Gefahr, versteht sich. Viel Spaß und Erfolg beim stabilen Übertakten!

V1.10 ShirKhan + KI 07.25​

 

[PCGH_Sven]

Danke für den tollen Content @ShirKhan, welcher sich um 15 Uhr verdientermaßen auf unserer Startseite wiederfindet.

Die CPU-Stabilität mittels Software-Kompilierung unter Linux zu testen, kann bislang unentdeckte Instabilitäten ans Licht bringen. Das kann ich aus eigener Erfahrung bestätigen.

Sehr nützliche Anleitung für die Community!

Liebe Grüße
Sven

 

[hellm]

Das kann ich aus eigener Erfahrung bestätigen.

Kann ich mich einreihen. Meine E-Cores haben es ein halbes Jahr geschafft mich ein wenig an der Nase und so.. nun ist es raus.

Kommt davon, wenn man die Zeit nicht hat (haben will) und die üblichen Werkzeuge und Games keine Fehler melden. Da wirds halt auf das verbuggte Stalker 2 geschoben, zuviel RAM-OC oder einen Bug weil der Release noch nicht lange her ist. Hat sich unter Windows nur sehr, sehr selten bemerkbar gemacht, die harten Workloads liefen durch, blieb unter dem Radar.

 

[Jaffech]

Mein Setting ist eins der im FAQ erwähnten "nicht instabilen".
Alles richtig gemacht würde ich sagen

@PCGH_Dave hau mal deinen 9950X3D da durch mit 6400/2133 Setting. Würde mich interessieren ob das durchrennt.
Dann kannste nebenbei auch CachyOS ausprobieren

 

[PCGH_Dave]

Ich nutze kein 6400/2133-Setting, sondern 6000/2200 und warum sollte ich jetzt Linux installieren, um meine CPU zu testen? Ich hab nicht mal eine freie SSD und auch keinen Platz mehr auf dem Board dafür. Hab hier keinen Bedarf daran und sehe ehrlich gesagt auch keinen Grund dafür, solange hier alles zufriedenstellend läuft.

 

[Gelöschtes Mitglied 23535a]

Danke @ShirKhan.

Meine Langzeit Mining Tests und meine Spieletests haben gesagt, das mein Rechner stabil ist. Erst beim Hive Knoten Compilieren ist mir aufgefallen, das der Arbeitsspeicher zu wenig Strom bekommen hat von mir.

0.05 Volt mehr haben es dann auch mehrmals sauber durchlaufen lassen.

Außerdem sieht des einfach nur Schnike aus, wenn die Zeilen in der Console rattern. Im Gegensatz zum für mich fast schon langweiligem Mining.^^

Ich lerne gerade erst wie das alles geht, deswegen ist so eine schöne Anleitung ein große Hilfe. Habe ich mir gleich mal Frech gespeichert.

 

[hellm]

Ich nutze kein 6400/2133-Setting, sondern 6000/2200 und warum sollte ich jetzt Linux installieren, um meine CPU zu testen? Ich hab nicht mal eine freie SSD und auch keinen Platz mehr auf dem Board dafür. Hab hier keinen Bedarf daran und sehe ehrlich gesagt auch keinen Grund dafür, solange hier alles zufriedenstellend läuft.

Guter Punkt. Das habe ich bei meinem Gaming-System (bis jetzt) auch nicht getan, mit Fedora will ich keine GeForce mehr genießen.

Also habe ich mir ein echtes Linux vom Live-Stick auf einen anderen USB-Stick installiert. Das geht unkompliziert und relativ fix, mit einem schnellen Stick (400/60MB/s read/write) ist das mehr als brauchbar. Fedora akzeptiert alles als Installationsziel, was partitioniert werden kann, ist wahrscheinlich bei vielen Distros so.
Da ich Fedora Cosmic genommen hatte, musste ich allerdings erst ein Update auf meinem Radeon-Rechner fahren, bevor ich auf meinem Geforce-Rechner booten konnte. Das ist auch genial an Linux, das stopfst irgendwo rein und es fährt hoch. Keine Sprüche wie "Einen Augenblick, wir richten für Sie ein..", keine Reboots.

@ShirKhan
Vielleicht noch ein kleines How-to: easy-peasy-permanent-Linux-on-a-stick?

 

[Philly78]

Lief sauber durch mit nem ARM auf SBC... 9:49M .. heisst das jetzt das alles in Ordnung ist?

Ich kompiliere schon seit 20 Jahren, mir ist es immer noch ein rätsel wie diese Idee besser als bewährte Benchmarks sein soll?

Gerade beim kompilieren zählen eigentlich schnelle Festplatten. Man könnte die Sourcen in eine Ramdisk schieben um wirklich schnell zu kompilieren.

 

[Jaffech]

Ich nutze kein 6400/2133-Setting, sondern 6000/2200

Ich weiß dass du 6000/2200 daily nutzt..

Du hast im OC Tagebuch aber auch 6400/2133 als Vergleich gehabt und darauf bezogen wirken die Ergebnisse dort als wäre da was nicht ganz stabil.

Deshalb, wie gesagt, würde mich interessieren ob das durch die Kompilierung rennt.

Ich hab nicht mal eine freie SSD und auch keinen Platz mehr auf dem Board dafür.

Geht auch easy über nen USB Stick, der halbwegs modern und schnell ist

Hab hier keinen Bedarf daran und sehe ehrlich gesagt auch keinen Grund dafür, solange hier alles zufriedenstellend läuft.

Sehr schade. Hatte eigentlich damit gerechnet dass du das ausprobieren würdest...

 

[Olstyle]

Lief sauber durch mit nem ARM auf SBC... 9:49M .. heisst das jetzt das alles in Ordnung ist?

Nö.
Was hier komplett fehlt ist ein Vergleich des Ergebnisses mit einem Sollzustand.
Der gleiche Compiler mit den gleichen Settings muss auch das gleiche binary ausspucken (wenn im make Vorgang kein aktuelles Datum eingebaut wird o.Ä.).
Stimmt der Hash der selbst gebauten Binary mit der unter Umständen auch bei git angebotenen Referenz binary überein, DANN ist alles in Ordnung.

 

[hellm]

Gerade beim kompilieren zählen eigentlich schnelle Festplatten.

Auch, kompilieren kann man ja vieles. Hier ist Schreibrate kein Flaschenhals, wahrscheinlich weil der GCC auch das kann, einen Buffer nutzen.
Dieser "Test" schafft es auch mit USB-Stick und genannter Schreibrate einen Fehler zu finden, der unter Windows den üblichen Tools wie Cinebench vorenthalten geblieben ist. Der Fehler bei meinem OC war auch nicht eingebildet, Tempest Rising hatte mich neulich 3x auf den Desktop geschickt. Stalker 2 und andere aber immer erfolgreich die Shader kompiliert.

Der gleiche Compiler mit den gleichen Settings muss auch das gleiche binary ausspucken (wenn im make Vorgang kein aktuelles Datum eingebaut wird o.Ä.).

Die Compiler Options kann man auch bezüglich RAM-Auslastung anpassen und was nicht. Dann kanns auch zu Fehlern kommen, die nichts mit der CPU und deren Stabilität zu tun haben.

Davon ab langt die Fehlerausgabe erstmal, nachweislich. Solange der Compiler keine Stunts fahren muss, wird das Ergebnis auch wie vorgesehen sein, Datum usw. mal außen vor gelassen.

Für einen absolut sicheren (gibts nicht) und wiederholbaren Test, einen Benchmark, da gebe ich dir recht. Sollte die Konfiguration mit Cmake nicht ausreichend sein? Für mich faule Sau macht das ja immer irgend ne IDE..

 

[PCGH_Dave]

Ich weiß dass du 6000/2200 daily nutzt..

Du hast im OC Tagebuch aber auch 6400/2133 als Vergleich gehabt und darauf bezogen wirken die Ergebnisse dort als wäre da was nicht ganz stabil.

Ja, für 6400 reicht die SoC-Spannung nicht aus. Stabil ist es hingegen, mit diversen Tools getestet. Aber das bringt mir dann ja nichts ^^

Sehr schade. Hatte eigentlich damit gerechnet dass du das ausprobieren würdest...

Wenn Linux jetzt plötzlich auf 80 Prozent der PCs in ganz DE läuft, dann passen wir auch gern unsere Benchmark-Maschinen daran an. Privat hingegen überlege ich mir zwei mal, wo ich meine Zeit investiere. Und "tagelang in Linux einarbeiten und Alternativen für fast alle Tools, die ich nutze suchen" klingt einfach nicht attraktiv für mich.

Es ist schön, dass es eine Alternative zu Windows gibt, aber ich bin nach einer anfänglichen Durststrecke zufrieden mit meinem Win 10. Wenn es also technisch, zeitlich und beruflich keinen Grund für den Tausch gibt, mache ich den Andreas ("Das bleibt hier alles so wie es ist!!!!).

 

[Jaffech]

Ja, für 6400 reicht die SoC-Spannung nicht aus. Stabil ist es hingegen, mit diversen Tools getestet. Aber das bringt mir dann ja nichts ^^

Wenn die SoC Spannung nicht ausreicht und es in die Fehlerkorrektur läuft, ist es nicht stabil^^
Nur weil du keinen BSOD bekommst heißt das nicht dass es stabil ist, Leistung muss auch passen.
Aber das weißt du ja sowieso

Wenn Linux jetzt plötzlich auf 80 Prozent der PCs in ganz DE läuft, dann passen wir auch gern unsere Benchmark-Maschinen daran an. Privat hingegen überlege ich mir zwei mal, wo ich meine Zeit investiere. Und "tagelang in Linux einarbeiten und Alternativen für fast alle Tools, die ich nutze suchen" klingt einfach nicht attraktiv für mich.

Die Anleitung von ShirKhan kannst du Copy/Pasten, hatte das auch getestet. Anfangs gabs bisschen Probleme, ist hier in der Anleitung aber gefixt.
Dauert vlt 5-10 min + Benchzeit (beim 9950X3D vermutlich <7min)

Es ist schön, dass es eine Alternative zu Windows gibt, aber ich bin nach einer anfänglichen Durststrecke zufrieden mit meinem Win 10.

Mit Win10 bin ich auch absolut zufrieden (gewesen).
Jetzt nach knapp 1,5 Wochen Linux only will ich aber tatsächlich nicht zurück.
Es ist irgendwie ein befreiendes Gefühl, ich weiß auch nicht wie ich das beschreiben soll ^^

mache ich den Andreas ("Das bleibt hier alles so wie es ist!!!!).

 

[empy]

Geht auch easy über nen USB Stick, der halbwegs modern und schnell ist

Oder per WSL?

 

[Jaffech]

Vermutlich ja.
Aber einen Stabitest in einer Emulation durchführen? Ich weiß ja nicht ^^

 

[empy]

Aber einen Stabitest in einer Emulation durchführen? Ich weiß ja nicht ^^

Naja, eher Virtualisierung als Emulation, aber ja, unter Umständen ist die Instruktionsdichte dann nicht ganz so hoch.

 

[PCGH_Dave]

Die Anleitung von ShirKhan kannst du Copy/Pasten, hatte das auch getestet. Anfangs gabs bisschen Probleme, ist hier in der Anleitung aber gefixt.
Dauert vlt 5-10 min + Benchzeit (beim 9950X3D vermutlich <7min)

Stell dir vor, ich sitze da, esse ganz entspannt mein Lieblingsgericht mit Messer und Gabel – funktioniert super, alles liegt gut in der Hand, ich bin satt und glücklich. Und dann kommst du vorbei, reißt mir fast das Besteck weg und rufst: 'Warum nimmst du nicht Stäbchen? Die sind viel eleganter, du hast mehr Kontrolle, und sie zwingen dich, dein Essen wirklich zu verstehen!' Ich verstehe schon, dass du Stäbchen liebst.

Ich hab dagegen kein Bedürfnis, mein Essen zu verstehen – ich will’s einfach nur genießen, ohne dass mir was zwischen den Fingern durchrutscht. Windows ist für mich wie die Gabel: Bekannt, verlässlich, erfüllt nach einigen Anpassungen genau meinen Zweck. Du darfst gern mit Stäbchen jonglieren, Konfigurationen meditativ eintippen und dein System bis aufs letzte Bit selbst verwalten. Aber ich bin nicht auf der Suche nach Erleuchtung beim Datei-Explorer – mir reicht es, wenn ich mich privat für inzwischen Jahre (!) durch etliche Ryzen-Systeme kämpfe. Und wenn ich mal ganz viel Lust habe, etwas Neues auszuprobieren, ja dann, vielleicht, wird es Linux. Eher werde ich die Zeit aber lieber mit meinem Sohn verbringen. Oder mal meinen Pile of Shame angehen, der "dank" dieses Jobs hier kontinuierlich wächst.

 

[Jaffech]

Stell dir vor, ich sitze da, esse ganz entspannt mein Lieblingsgericht mit Messer und Gabel – funktioniert super, alles liegt gut in der Hand, ich bin satt und glücklich. Und dann kommst du vorbei, reißt mir fast das Besteck weg und rufst: 'Warum nimmst du nicht Stäbchen? Die sind viel eleganter, du hast mehr Kontrolle, und sie zwingen dich, dein Essen wirklich zu verstehen!' Ich verstehe schon, dass du Stäbchen liebst.

Das ist aber schon ein echt richtig wilder Vergleich

Vor allem weil es nur drum geht mal das 6400/2133 Setting zu testen, weils mich dein OC Tagebuch so gefesselt hat und in mir eben die Frage aufkam ob die fehlende SoC Spannung beim kompilieren einen Fehler wirft...
Keine Ahnung wie du da jetzt drauf kommst, ich wolle dich zu Linux "umerziehen" oder sonst was...

Ich hab dagegen kein Bedürfnis, mein Essen zu verstehen – ich will’s einfach nur genießen, ohne dass mir was zwischen den Fingern durchrutscht. Windows ist für mich wie die Gabel: Bekannt, verlässlich, erfüllt nach einigen Anpassungen genau meinen Zweck. Du darfst gern mit Stäbchen jonglieren, Konfigurationen meditativ eintippen und dein System bis aufs letzte Bit selbst verwalten. Aber ich bin nicht auf der Suche nach Erleuchtung beim Datei-Explorer – mir reicht es, wenn ich mich privat für inzwischen Jahre (!) durch etliche Ryzen-Systeme kämpfe. Und wenn ich mal ganz viel Lust habe, etwas Neues auszuprobieren, ja dann, vielleicht, wird es Linux. Eher werde ich die Zeit aber lieber mit meinem Sohn verbringen. Oder mal meinen Pile of Shame angehen, der "dank" dieses Jobs hier kontinuierlich wächst.

Mal kurz den Stabitest laufen lassen != "DU MUSST JETZT AUF LINUX UMSTEIGEN!!!"
Hä?

Finde deine Reaktion auf mein "Kannst du mal dein im OC Tagebuch benutztes 6400/2133 Setting damit testen?" schon sehr übertrieben.


Edit: Aber darum solls ja jetzt auch nicht weiter gehen, sondern um den alternativen Stabilitätstest allgemein ^^

 

[PCGH_Dave]

Ich hätte aktuell sogar nicht mal nen Stick dafür
Das würde mir nur Umstände machen, derzeit. Das 6400/2133-Setting habe ich abgeschrieben, weil es beim Zocken zu weniger Fps führt. Wenn ich also nicht per LN2-Mode mehr Spannung reinballere, hat es keinen Sinn, da noch eine Sekunde Zeit zu investieren

 

[hellm]

Wenn ich also nicht per LN2-Mode mehr Spannung reinballere, hat es keinen Sinn, da noch eine Sekunde Zeit zu investieren

Ist doch OK. Ich gehöre nicht zu den gefühlten 80% Linuxnutzern, mein Gaming Tower hat kein Linux. Allerdings bin ich schon seit längerer Zeit Gelegenheits-, Hobby- und Umstands-Linuxnutzer. Aber eben Fedora, keine getunte Gaming-Distro.

Ich mag Windows. Ich mag mein Office, mein Teams (mein Notepad++, u.v.m.) und inzwischen auch schon meinen M$-Account. Mein Linux gibt mir die Freiheit das auch genießen zu können. Klingt komisch, ist aber so.

Wenn du keinen USB-Stick dafür abstellen kannst, du bräuchtest idealerweise einen zweiten für eine echte Installation, dann gibt es weiterhin genug andere Möglichkeiten.
Eine AMD-CPU ist ja zumindest nur mit einer Sorte Kern unterwegs, ist ja nicht so, als ob die Tools unter Windows überfordert wären. Für uns Intel-OC-Weltmeister ist der Test aber nicht selten eine Offenbarung.

Davon ab, es ist möglich Git auf Windows zu installieren, ebenso den GCC, make und Cmake. Das alles kann man also wunderbar in der PowerShell von Windows ausführen. Die AI Ihrer Wahl berät Sie gerne.