Arbeitsspeicher-Stabilität testen - Aber richtig!

Eigentlich ein ziemlich langweiliger Titel oder? Keine Sorge, ich denke am Ende werden hier ein paar sehr unerwartete Erkenntnisse vermittelt, die für jeden PC-Nutzer wertvoll sein können, aber Eins nach dem Anderen.

Warum das Ganze?

In unserem täglichen (IT-)Leben gibt es eine ganze Menge Dinge, die wir einfach so hinnehmen, weil sie entweder schon immer so waren, oder weil wir noch nie darüber nachgedacht haben. In der IT mehr als irgendwo sonst ändern sich Paradigmen aber von Zeit zu Zeit. Wissen, welches schlicht als richtig angenommen wird, ist es im Zweifel einfach nicht mehr, z.B. weil sich eine zugrunde liegende Technologie insoweit verändert hat, dass einige unserer lang gehegten und geliebten Eselsbrücken sich als mittlerweile obsolet herausgestellt haben. Sehr gut kann man das bei vielen Annahmen beobachten, die mit Festplatten zu tun haben. Seit wir hauptsächlich Flash-Medien benutzen (SSDs, NVMEs), treffen viele der alten “Wahrheiten” einfach nicht mehr zu. Ähnliches gilt auch für andere Bereiche und hier soll es um den Arbeitsspeicher gehen, speziell um die Stabilität eben dessen, aber zuerst ein paar Grundlagen.

Hintergrund

Die meisten Desktop-Mainboards haben 2 RAM-Channels, in seltenen Fällen (Embedded-Mainboards und manche Mini-ITX-Boards) auch nur einen. Server- und Workstation-Mainboards haben 3 oder 4, im Extremfall auch bis zu 6 oder 8 Channels (teilweise pro CPU!). An jedem Kanal hängen meist 2 Arbeitsspeicher-Slots, in welche die Riegel eingesteckt werden können, bei Servern auch gerne mehr. Zu einer Zeit, als wir noch von Southbridge und Northbridge gesprochen haben (die Älteren werden sich erinnern) war der Controller für den Arbeitsspeicher in der Northbridge. Irgendwann (ab ca. Intel Core-i und AMD K-8 Generation) gab es dann nur noch “den Chipsatz”, weil für die meisten Platformen der RAM-Controller direkt in die CPU gewandert ist. Hier wären wir schon mal beim ersten Punkt, der nicht ganz offensichtlich ist: Die Stabilität des Arbeitsspeichers hängt ganz maßgeblich von der CPU ab, nicht nur vom Mainboard (und dessen BIOS/uEFI) und dem RAM selbst. Und die Qualität der CPU ist zufällig. Die eine CPU kann eine überdurchschnittlich gute Leistung haben, eine andere CPU des selben Modells eben nicht. Das passende Schlagwort dazu heißt “Silicon Lottery”.

Die Gamer

Wenn Sie sich für Hardware interessieren, landen Sie oft bei Informationsquellen, die sich eher an die Nische der Gamer richten, unabhängig davon, ob Sie selbst Computerspiele spielen. Dort scheint die Medienlandschaft hauptsächlich aus Benchmarks zu bestehen. Noch extremer wird das, wenn es in den Overclocking-Bereich geht. Das ganze ist relativ analog zur Gemeinde der KFZ-Enthusiasten (um nicht zu sagen “Tuner”) zu sehen. Auch wenn man vielleicht selbst nicht mit dieser Sparte identifizieren kann, gibt es grade doch hier oft die besten (technischen) Informationen und das meist viel früher als anderswo. Prinzipiell also eine wertvolle Informationsquelle. Das Problem das sich ergibt ist, dass wenn man in technischen Randbereichen unterwegs ist, “Stabilität” etwas ganz anderes bedeutet als Alltagstauglichkeit. Oft wird einmal ein Spiel angetestet, und ansonsten noch ein Benchmark mit z.B. Cinebench durchgeführt, und das wars. Damit ist es für den durchschnittlichen Overclocker “stabil”, wenn der Rechner dabei nicht abstürzt. Während sich die Overclocker und Gamer hauptsächlich um die CPUs und Grafikkarten kümmern und vielleicht noch um diverse Mainboard-Features, wird der Bereich RAM oft nur Stiefmütterlich behandelt: “XMP/EXPO/DOCP anschalten, und fertig”. Leider ist das nur die halbe Wahrheit, und wenn einige Ihrer Systeme seltsame Instabilitäten zeigen, die man sich schlecht erklären kann, diese aber vielleicht zu selten auftreten, um das Problem mal ernsthaft anzugehen, ist auch (und teilweise grade) bei aktuellen Systemen tatsächlich hier oftmals der RAM schuld.

Arbeitsspeicher-Technik

Das gute zuerst: RAM ist heute nicht nur billiger, sondern auch viel schneller und stabiler als früher. Auch gehen die Riegel weniger oft kaputt als früher. Das Übertakten als gratis Performance-Boost geht heute einfacher denn je. Schon seit langem gibt es die “JEDEC”. Das ist ein Standartisierungs-Gremium, was technische Details zu Arbeitsspeicher-Technologien spezifiziert, und dazu gehören auch die Taktraten. Mehr noch, man kann sogar als für gut befundene Kombinationen von Takt, Spannung und Timings im RAM-Riegel selbst als Profil hinterlegen, damit das Mainboard oder geeignete Software (z.B. CPU-Z unter Windows oder decode-dimms unter Linux) diese einfach auslesen und benutzen können. Der derzeit höchste für DDR5 spezifizierte Takt ist im übrigen 8800MT/s, doch das ist ständig im Wandel. Beim Erscheinen von DDR5 lag die JEDEC-Grenze irgendwo in den 4000er-Bereichen. Möglicherweise werden Sie jetzt den Finger heben und “Moooooment” rufen, weil man RAM, der mit 6000MHz, 8000MHz oder noch mehr MHz kaufen kann (MHz und MT/s ist fürs bessere Verständnis hier mal äquivalent, auch wenn das etwas vereinfacht dargestellt ist). Außerdem war da nicht letztens irgendwas, dass die ersten Overclocker RAM auch mit über 10000 oder 12000 MHz auf DDR5 betrieben haben?

…Ja, stimmt genau, und da fängt das Problem bei Arbeitsspeichern auch erst an. Wenn Sie heutzutage DDR5-RAM haben, der sagen wir mal schneller als mit 4800 oder 5600 MHz beworben wird, können Sie davon ausgehen, dass das alles deutlich außerhalb der normalen Spezifikation stattfindet. Nehmen Sie sich eins der o.G. Tools zur Hand, und prüfen das einfach selber nach. Wahrscheinlich werden Sie 2-3 JEDEC-Profile auf dem RAM-Riegel kodiert haben und ggf. zusätzlich noch eines, was z.B. mit XMP oder EXPO gekennzeichnet ist, und nur dieses wird der Geschwindigkeit auf der Packung entsprechen. Inwieweit man hier von Mogelpackung sprechen darf, darüber streiten sich die Geister, denn die beworbene Geschwindigkeit ist für gewöhnlich nur zu erreichen, wenn man eine günstige Kombination von CPU, Mainboard, RAM, BIOS-Version und einem wohlgesonnenen Horoskop erwischt. Diese Art von Marketing war bei Arbeitsspeicher eigentlich schon immer so, aber heutzutage müssen deutlich mehr Sterne richtig stehen, um die entsprechenden Geschwindigkeiten auch erreichen zu können.

XMP, DOCP und EXPO

Eigentlich sind das 3 verschiedene herstellerspezifische Abkürzungen für mehr oder weniger dasselbe: “Die Anwendung eines im Arbeitsspeicher hinterlegten Profils, um die höchste Geschwindigkeit an den RAM anzulegen, die dieser technisch beherrscht, ohne Fehler zu produzieren.” Da höhere Taktraten auch u.a. höhere Spannungen und andere Sub-Timings auf dem RAM erfordern, wird das Ganze als Profil zusammengefasst, damit das RAM-Overclocking zur “1-Klick-Aktion” im BIOS wird. So weit, so gut. Leider funktioniert das in der Realität oftmals nur bedingt. Grundsätzlich kann man sagen, dass bei aktuellen x86-Architekturen höhere RAM-Geschwindigkeiten bei Intel besser funktionieren als bei AMD. Vermutlich weil Intel organisatorisch näher an den entsprechenden Gremien sitzt. Aktuell im Sinne von Desktop-Hardware zum Zeitpunkt der Erstellung dieses Artikels ist AM5 mit Ryzen 7xxx/8xxx bei AMD und Core-i-12th/13th Gen bei Intel (beide DDR5). Wenn Ihr Mainboard mal defekt sein sollte, sollten Sie im übrigen nicht angeben, das Sie XMP und Co. aktiviert haben. Viele Mainboardhersteller sehen das bereits als “Overclocking” an, und verweigern aufgrund dessen die Garantie, unabhängig von der Art des Defektes.

Und was geht mich das eigentlich an?

Aufgrund der immer öfter zu hörenden Kritik insbesondere aus dem Gamer-Bereich, dass OEM-Hersteller standardmäßig XMP und Co. im Auslieferungszustand NICHT eingeschaltet haben, gehen viele Hersteller genau dazu über. Leider ist das XMP-Profil sehr oft instabil in Kombination mit dem Rest der verwendeten Hardware. Oftmals grade so, dass der Rechner normal läuft, aber sich scheinbar zufällige Instabilitäten einstellen. Möglicherweise gehören Sie auch zu den Power-Usern, die gerne viel RAM zur Verfügung haben wollen und daher immer alle 4 Slots mit Arbeitsspeicher bestücken. In so einem Fall können Sie bei schnellem RAM eigentlich gleich davon absehen, die beworbene Geschwindigkeit nutzen zu können, denn mehr als ein Riegel pro RAM-Kanal erhöht deutlich die elektische Last auf den RAM und vor allem den Controller. Ein stabiler Betrieb wird dann in der Regel nicht möglich sein (DAS steht so natürlich nicht auf der Verpackung). Bei Servern hat man das Problem normalerweise nicht, denn der dort normalerweise benutzte ECC-RAM hat üblicherweise nur stabile JEDEC-Profile mit niedrigerern Frequenzen.

Realistischerweise ist “schnellerer RAM” schon auch “besserer RAM”. Die zusätzliche Geschwindigkeit zu nutzen ist also auf jeden Fall insoweit sinnvoll, wie das Ganze sich auch wirklich stabil betreiben lässt. Für Spiele ist das nur selten entscheidend, aber für typische Poweruser-Tasks (Datei(de)komprimierung, Code-Kompilierung, Crypto-Anwendungen/Hashing, Foto-/Video-Bearbeitung) kann das einen deutlichen Unterschied machen. Wie üblich ist es aber auch hier so, dass “mehr RAM” immer mehr bringt als “schnellerer RAM”. Ebenfalls sollten Sie immer alle RAM-Kanäle (nicht dasselbe wie “alle RAM-Slots”) bestücken, denn sonst läuft der RAM grundsätzlich nur mit halber Geschwindigkeit.

Step-by-Step

Als allerersten Schritt muss man sich die Frage stellen: “Sind alle meine Arbeitsspeicher-Module vom gleichen Hersteller und Typ?” Falls nicht, sollte man hier aufhören. Verschiedene Module können schon mal gut zusammenspielen, tun es aber in der Regel eher nicht.

Als nächstes das BIOS: Während man früher nur in Ausnahmefällen und bei Problemen das Risiko auf sich nahm, das BIOS zu updaten, ist das heute leider schon fast die Grundvorraussetzung, denn die Menge an Kinderkrankheiten sind über die Jahre immer mehr und nicht weniger geworden. Schon aus Security-Sicht sollte man immer ein aktuelles BIOS/UEFI anstreben. Grade RAM-Performance-Probleme gehören heute zu den üblichen Dingen, die ein neues BIOS im Zweifel behebt oder zumindest deutlich verbessern kann.

Als nächstes sollte ein Stresstest der Zielkonfiguration vorgenommen werden. Am einfachsten geht das mit memtest86+. Wenn Sie Linux benutzen, kann man das in den meisten Distributionen einfach installieren, und hat dann direkt einen neuen bootbaren Eintrag dafür. Ansonsten geht aber auch ein Live-Medium der gängigen Linux-Distributionen, die memtest auf ihrem Datenträger oft im Bootmenü mitbringen. Alternativ kann man Multi-Boot-Lösungen wie Ventoy verwenden. Es gibt viele Wege, die hier zum Ziel führen. Ein RAM-Test sollte mindestens einmal, besser zweimal komplett ohne Fehler durchlaufen, was meist ein paar Stunden dauert. Wenn man Fehler beobachtet, sollte man Schrittweise den RAM-Takt im BIOS soweit senken, bis keine Fehler mehr auftreten und dann noch mal zur Sicherheit eine Stufe niedriger und nochmal testen. Wenn RAM-Riegel wirklich defekt sind, muss man die Riegel einzeln testen.

Was also tun, wenn trotzdem Fehler auftreten?

Bis hierhin haben Sie die einzelnen Maßnahmen vielleicht schon mal gehört, und ggf. auch selber schon oft so oder so ähnlich angewendet. Es kann aber durchaus sein, dass wir uns auf dem schmalen Grat bewegen, in dem memtest sauber durchläuft, aber man trotzdem Instabilitäten beobachtet, die am ehesten auf den RAM zurückzuführen sind, aber man einfach keine gute Möglichkeit hat, das Problem weitergehend zu diagnostizieren. Manchmal treten solche Probleme auch von jetzt auf gleich ohne ersichtlichen Grund auf - manchmal auch erst nach Monaten - sind dann vielleicht aber von da an sogar persistent. Das Problem hört sich esoterisch an, aber mir ist das schon bei 3 aktuellen Rechner passiert, dass ich mit aktiviertem XMP/EXPO in genau diesem teilstabilen Bereich gelandet bin, wenn ich alle RAM-Slots ausgenutzt habe.

Wenn man das Problem logisch angeht, wäre die Überlegung, etwas zu finden, was sehr sensibel auf RAM-Fehler reagiert, idealerweise ohne dass der Rechner dabei abstürzt. Ein Computerspiel dass “irgendwann zwischen 5 Minuten und 2 Stunden nach dem Start” abstürzt, ist also schon mal keine verlässliche Metrik. Glücklicherweise haben wir in jeder gängigen Linux-Distribution etwas dabei, dass eigentlich für was ganz anderes gedacht ist, aber genau in unseren Anwendungsfall fällt, und das ist luks (spezifischer luks2). Luks [1] ist eigentlich dazu da, unter Linux Festplattenverschlüsselung zu ermöglichen, aber wie es der Zufall so will lässt sich luks perfekt für unsere Zwecke missbrauchen. Luks2 benutzt - im Gegensatz zur ersten Version - argon2 [2] als Schlüssel-Ableitungsfunktion für kryptografische Hashes. Da argon2 eher “mehr RAM” als “mehr CPU” beim Hashing benutzt, reagiert es ausgesprochen sensitiv auf Arbeitsspeicherfehler. memtest hingegen schreibt einfach nur immer wieder kurze, wechselnde Zeichenfolgen in den RAM und liest sie wieder aus, in der Hoffnung, eine Diskrepanz feststellen zu können.

Sinnvoll Testen

Die Idee ist also folgende:

Wir erstellen uns eine Datei von z.B. 1GB Größe, die wir als Festplatte bzw. Festplattenimage benutzen, formatieren diese mit Luks, schreiben unser Passwort in eine Datei, und nutzen die Luks Bordmittel, um zu prüfen, ob man mit diesem Passwort die Datei entschlüsseln kann. Das ganze machen wir z.B. 100 mal nacheinander. Wenn sich hierbei Fehler zeigen, wissen wir, dass wir unseren RAM etwas zu hoch getaktet haben.

Ich habe das mal exemplarisch für mein System durchgespielt. Testhardware: ASUS x670E-Mainboard, AMD Ryzen 9 7900x, 4x16GB Corsair-RAM 6000MT-36-36-36-76-1,35V. Ich habe das Expo-Profil im BIOS geladen, und dann nur die Taktrate wieder runtergestellt. So sind Timings und Spannung schon mal übertaktet, aber beim Takt arbeiten wir uns nach oben hin vor. Angefangen bei 3600MT (der automatischen Einstellung) zeigten sich bereits bei 4400MT/s im luks-Test erste Fehler, und erst bei 4800MT/s hat man die Fehler in memtest gesehen. Da hat unser Script schon nur noch in Ausnahmefällen mal einen erfolgreichen Lauf gehabt. Bei 5200MT/s hat der Rechner nicht mehr gebootet. Die beworbene RAM-Geschwindigkeit ist hier wohlgemerkt 6000MT/s. In meiner Konfiguration ist also 4400MT/s das höchste der Gefühle mit 4 RAM-Riegeln. Ich habe also auf 4200MT zurückgestellt, und das erst einmal so gelassen.

Kürzlich gab es für mein Mainboard ein BIOS/UEFI-Update, das insb. die RAM-Stabilität und Kompatibilität verbessern sollte, also war ich neugierig. Und tatsächlich, mit dem neuen BIOS ist es nun möglich alle 4 Riegel auf 6000MT/s zu betreiben, sogar bei 6400MT/s war noch alles stabil, erst bei 6800MT/s wollte das System nicht mehr booten. Allerdings hat sich hier auch noch eine andere Beobachtung ergeben: Das System hat ab ca. 5600MT/s mit jeder Erhöhung der Taktrate länger zum Booten gebraucht, und zwar deutlich. Bei 6400MT/s hat sich die Bootzeit (der erste Teil des Bootens, wo der Bildschirm normalerweise noch dunkel ist) mehr als verzehnfacht. Der Grund dafür ist, dass das BIOS erst mal den RAM “anlernen” muss, also testen muss, welche Frequenzen überhaupt möglich sind, ohne gleich dabei abzustürzen und dann, ob die gewünschte Frequenz überhaupt so stabil ist, dass wir ins BIOS kommen. Das braucht Zeit, besonders wenn wir an der Grenze der noch vertretbaren Geschwindigkeit sind.

Auf einem anderen System (Gigabyte x570 Mainboard, AMD Ryzen 9 3900x, 4x16GB Corsair Ram mit 3200MT/s) sieht das Ähnlich aus: Bei der Basiskonfiguration von 2100MT/s ist alles in Ordnung, beim XMP-Profil von 3200MT/s zeigt memtest keine Auffälligkeiten, aber unser Script offenbart eine Fehlerrate von etwas über 20%. Das heißt, jeder fünfte Versuch, ein verschlüsseltes Laufwerk zu entschlüsseln schlägt fehl. Erst 2666MT/s war hier schlussendlich eine stabile Konfiguration.

Fazit

Das Fazit fällt kurz aus:
- Man sollte immer mal wieder den Zustand seines Arbeitsspeichers testen, grade wenn hin und wieder seltsames Verhalten auftritt. Eine einmal für gut befundene Konfiguration ist notwendigerweise nicht ewig gut
- Man sollte die Firmware seines Rechners (inkl. UEFI/BIOS) aktuell halten
- Mehr RAM bringt mehr als schneller RAM
- RAM-Geschwindigkeit zu nutzen ist sinnvoll, aber nur solange man die Stabilität auch sicher gewährleisten kann
- Man kann bei verschlüsselten Laufwerken nicht ausschließen, dass RAM-Fehler am Ende nicht zu einer korrupten Partition und damit einhergehend zu Datenverlust führt!

Script

Um das ganze einfacher zu Testen, habe ich ein kleines Bash-Skript (das ganze Skript am Ende des Artikels) gebaut, um einfacher testen zu können. Für das Script müssen luks dd und pwgen installiert sein. Die Anzahl, wie viele Durchläufe man testen will, kann man als Argument übergeben. Das Ergebnis sieht dann so aus:

user@ubuntu $ test/ramtest.sh 5
dd, luks und pwgen vorhanden. Fahre fort.
Anzahl der Durchläufe ist 5
Lege temporäres Verzeichnis /tmp/tmp.A6FlwUUxkB an
Lege temporäres Image der Größe 1000MB an
formatiere image mit luks
Durchlauf Nummer 1 von 5
Durchlauf Nummer 2 von 5
Durchlauf Nummer 3 von 5
Durchlauf Nummer 4 von 5
Durchlauf Nummer 5 von 5

Resultat:
Anzahl Durchläufe: 5
Erfolgreiche Durchläufe: 5
Nicht erfolgreiche Durchläufe: 0

Entferne temporäres Verzeichnis /tmp/tmp.A6FlwUUxkB
user@ubuntu $

Und hier das komplette Script. Einfach speichern, ausführbar machen und mit der gewünschten Anzahl aufrufen. Viel Spass beim Testen.

#!/bin/bash

# Dieses script soll ramfehler mittels luks finden
# Benutzung: ./ramtest.sh <anzahlDurchläufe>

if
        which dd > /dev/null && which cryptsetup > /dev/null && which pwgen > /dev/null
then
        echo "dd, luks und pwgen vorhanden. Fahre fort."
else
        echo "dd, luks und/oder pwgen nicht installiert."
        exit 1
fi

if [[ -n $1 ]] && [[ $1 =~ ^[0-9]+$ ]]
then
        COUNT=$1
        echo "Anzahl der Durchläufe ist $COUNT"
else
        echo "keine Anzahl übergeben oder keine Zahl"
        exit 1
fi

TMPDIR=$(mktemp -d)
echo "Lege temporäres Verzeichnis $TMPDIR an"

PW=$(pwgen 64 -1)
PWFILE="$TMPDIR/pw"

echo $PW > $PWFILE

echo "Lege temporäres Image der Größe 1000MB an"
dd if=/dev/urandom of=$TMPDIR/ramtest.img bs=1M count=1000 2>/dev/null

echo "formatiere image mit luks"
cryptsetup  luksFormat $TMPDIR/ramtest.img < $PWFILE
> $TMPDIR/log
for i in $(seq 1 $COUNT)
        do
            echo "Durchlauf Nummer $i von $COUNT"
            cryptsetup luksOpen --test-passphrase $TMPDIR/ramtest.img < $PWFILE 2>/dev/null
            RES=$?
            if [[ $RES -eq 0 ]]
            then
                echo "0" >> $TMPDIR/log
            else
                echo "1" >> $TMPDIR/log
            fi
            unset RES
        done

echo -e "\n\
Resultat: \n\
Anzahl Durchläufe: $COUNT \n\
Erfolgreiche Durchläufe: $(grep ^0$ $TMPDIR/log | wc -l) \n\
Nicht erfolgreiche Durchläufe: $(grep ^1$ $TMPDIR/log | wc -l) \n"

echo "Entferne temporäres Verzeichnis $TMPDIR"
rm -Rf $TMPDIR
exit 0

Ein Tipp von Kai.

[1] https://de.wikipedia.org/wiki/Dm-crypt#LUKS
[2] https://de.wikipedia.org/wiki/Argon2