Wie optimiert man die CPU für RandomX-Mining? (L3-Cache-Fix)

RandomX- und CPU-Cache-Abhängigkeiten verstehen

1. RandomX ist ein speicherintensiver Proof-of-Work-Algorithmus, der speziell für das CPU-Mining entwickelt wurde und den Schwerpunkt auf große Mengen schnellen Speicherzugriffs und nicht auf rohen Rechendurchsatz legt.

2. Es ist stark auf die L3-Cache-Bandbreite und -Latenz angewiesen, um bei der Ausführung seiner Routinen für virtuelle Maschinen eine hohe Befehls-pro-Zyklus-Effizienz aufrechtzuerhalten.

3. Moderne AMD Ryzen- und Intel Core-Prozessoren weisen mehreren CPU-Kernen gemeinsam genutzten L3-Cache zu, aber die standardmäßige Betriebssystemplanung und BIOS-Einstellungen führen oft zu einer suboptimalen Cache-Nutzung.

4. Cache-Zeilenkonflikte, falsches Teilen und NUMA-Knoten-Ungleichgewicht beeinträchtigen die Konsistenz der Hash-Rate, selbst wenn die Temperatur- und Leistungsgrenzen nicht überschritten werden.

5. Die Datensatzgröße des Algorithmus – etwa 256 MB pro Instanz – ist bewusst so abgestimmt, dass sie in typische L3-Caches der Verbraucherklasse passt, was die Cache-Partitionierung zu einem entscheidenden Optimierungsvektor macht.

L3-Cache-Konfiguration auf BIOS-Ebene

1. Aktivieren Sie „Core Performance Boost“ oder „Precision Boost Overdrive“ nur, wenn die anhaltenden All-Core-Turbofrequenzen unter voller RandomX-Last stabil bleiben.

2. Deaktivieren Sie „C-States“ unter C1, um unvorhersehbares Core-Parking zu verhindern, das die Cache-Residency-Muster während aktiver Mining-Zyklen stört.

3. Stellen Sie „Speicherfrequenz“ auf das höchste vom Motherboard und den DIMMs unterstützte JEDEC- oder

4. Aktivieren Sie „LLC Prefetch“ oder „L3 Streamer“, falls verfügbar; Diese Funktionen verbessern die Vorhersagbarkeit des sequentiellen Zugriffs im gesamten Arbeitssatz des Datensatzes.

5. Stellen Sie auf AMD-Plattformen sicher, dass „Global C-State Control“ deaktiviert und „Core Level Power Management“ auf „Disabled“ eingestellt ist, um eine dynamische Cache-Neuzuweisung zwischen Kernen zu vermeiden.

Betriebssystem-Scheduler und Prozessaffinitätsoptimierung

1. Binden Sie jeden RandomX-Miner-Prozess mithilfe eines Tasksets oder CPU-Sets an einen dedizierten physischen Kern und vermeiden Sie Geschwister mit Hyperthreading, um Cache-Thrashing zu verhindern.

2. Verwenden Sie den Kernel-Boot-Parameter isolcpus=, um bestimmte Kerne aus der allgemeinen Scheduler-Domäne zu entfernen. Dies verhindert, dass Hintergrundinterrupts die L3-Cache-Zeilen verschmutzen.

3. Mounten Sie tmpfs unter /dev/shm mit einer Größe, die dem RandomX-Datensatz (256 MB) entspricht, und konfigurieren Sie Miner so, dass er es für die Scratchpad-Initialisierung verwendet – wodurch DRAM-Roundtrips reduziert werden.

4. Wenden Sie die Echtzeit-Planungspriorität (SCHED_FIFO) mit nice -20 und rlimit -rtprio 99 an, um den Kontextwechsel-Jitter während der VM-Ausführungsphasen zu minimieren.

5. Deaktivieren Sie transparente riesige Seiten (THP) über echo never > /sys/kernel/mm/transparent_hugepage/enabled, um eine Fragmentierung der Seitentabelle zu verhindern, die den TLB-Druck erhöht.

Überlegungen zur Wärme- und Spannungsstabilität

1. RandomX-Mining induziert eine anhaltende L3-Cache-Aktivität, was zu lokalisierten Die-Temperaturen führt, die bei instabilen Spannungskurven eine durch Unterspannung verursachte Beschädigung der Cache-Zeile auslösen können.

2. Überwachen Sie die L3-Belegung pro Kern mithilfe von Tools wie perf stat -e Cache-Referenzen, Cache-Misses, CPU-Zyklen -C 0 --no-buffer -I 1000 während des aktiven Hashings, um frühe Anzeichen einer Cache-Verschmutzung zu erkennen.

3. Vermeiden Sie aggressive Kurvenoptimierer-Offsets auf AMD-CPUs, es sei denn, dies wurde durch erweiterte Stresstests validiert, einschließlich randomx-benchmark --verify – Instabilität manifestiert sich als stille Hash-Fehler, bevor es zu thermischer Drosselung kommt.

4. Intel-CPUs profitieren von der vollständigen Deaktivierung von SpeedStep und der Sperrung der P-Zustände bei P1 (maximal ohne Turbo), um eine vorhersehbare L3-Latenz unter konstanter Last aufrechtzuerhalten.

5. Verwenden Sie MSR-Schreibbefehle, um adaptive L3-Cache-Zuweisungsrichtlinien wie Intels CAT oder AMDs ECORE zu deaktivieren und so eine statische 1:1-Kern-zu-Cache-Zuordnung zu erzwingen.

Häufig gestellte Fragen

F: Bietet eine Erhöhung der RAM-Geschwindigkeit über DDR4-3200 hinaus messbare Steigerungen der RandomX-Hash-Rate? Nicht wesentlich. Bei Dual-Channel-Konfigurationen kommt es bei etwa DDR4-2933 zu einer Speicherbandbreitensättigung. Weitere Steigerungen führen zu sinkenden Erträgen, sofern sie nicht mit engeren primären Timings und einer geringeren CAS-Latenz gepaart werden.

F: Kann ich zwei RandomX-Instanzen auf demselben physischen CPU-Paket ohne Leistungsverlust ausführen? Nein. Gemeinsame L3-Cache-Konflikte zwischen Instanzen führen zu einer Durchsatzverschlechterung von bis zu 38 % aufgrund von Räumungsdruck und erhöhten Fehlerraten – bestätigt in Ryzen 5000- und Comet Lake-Prüfständen.

F: Ist AVX-512 für RandomX-Mining auf kompatiblen Intel-CPUs von Vorteil? Nein. RandomX vermeidet absichtlich breite Vektoranweisungen, um die Zugänglichkeit der CPU zu gewährleisten. Die Aktivierung von AVX-512 löst höhere Basistakteinbußen und thermische Drosselung aus, ohne das Befehlsverteilungsmuster der VM zu verbessern.

F: Warum zeigt mein Ryzen 7 5800X trotz höherer Kernanzahl und größerem L3-Cache eine niedrigere Hashrate als ein Ryzen 5 5600X? Das gemeinsame L3-Design des 5800X führt bei anhaltenden Direktzugriffsmustern zu einer höheren Inter-Core-Latenz. Der kleinere, aber enger gekoppelte 32-MB-L3 des 5600X liefert bessere Trefferraten pro Zyklus in der Speicherdurchlaufschleife von RandomX.