Linux · Steam · Proton · Arch / CachyOS

Gaming-Tuning, Schritt für Schritt

Die üblichen Copy-&-Paste-„Optimierungsskripte" aus dem Netz setzen oft Dinge doppelt, gegeneinander oder mit Werkzeugen, die es auf Arch/CachyOS gar nicht gibt. Diese Anleitung macht dieselben Punkte einzeln, mit Begründung und einem Weg zurück.

CachyOS / ArchGameModeMangoHudDXVKUFW
01

Kernel & Scheduler

CachyOS bringt einen eigenen, für Desktop/Gaming vorkonfigurierten Kernel mit (Varianten wie linux-cachyos-bore mit dem BORE-Scheduler). Auf reinem Arch geht der gleiche Weg über das chaotic-aur-Repo oder manuell gebaute Kernel. Der Scheduler-Wechsel ist meist der Hebel mit dem besten Aufwand-Nutzen-Verhältnis – deutlich vor Governor-Basteleien.

# CachyOS: Kernel-Variante wählen und Scheduler setzen sudo pacman -S cachyos-kernel-manager kernel-manager # scx-Scheduler (sched-ext) statt starrem CFS/BORE-Only-Setup: sudo pacman -S scx-scheduler sudo systemctl enable --now scx_loader scx_loader --help
ZRAM statt Swap-Datei

Komprimierter RAM-Swap fängt kurze Speicherspitzen ab, ohne auf die SSD zu warten. Auf 32 GB+ Systemen reicht meist die Hälfte des RAMs als ZRAM-Größe, nicht 100 %:

sudo tee /etc/systemd/zram-generator.conf >/dev/null <<'EOF' [zram0] zram-size = ram / 2 compression-algorithm = zstd EOF sudo systemctl daemon-reexec sudo systemctl start systemd-zram-setup@zram0.service
02

CPU-Governor dem richtigen Dienst überlassen

Viele Tuning-Skripte setzen den Governor per Schleife direkt in /sys/…/scaling_governor. Das Problem: sobald power-profiles-daemon (Standard auf den meisten Desktop-Distros) oder tuned läuft, wird diese Änderung beim nächsten Profilwechsel oder Neustart kommentarlos überschrieben – man tunt gegen den eigenen Dienst.

# Wer verwaltet den Governor gerade? systemctl is-active power-profiles-daemon powerprofilesctl get # Performance-Profil aktivieren (statt manuell in scaling_governor zu schreiben) powerprofilesctl set performance
Nicht doppelt verwalten

Läuft power-profiles-daemon, sollte kein zweites Tool (eigenes Skript, cpupower-Service, TLP) parallel am Governor drehen. Zwei Verwalter für dieselbe Einstellung ist die häufigste Ursache für „die Einstellung hält nicht".

03

Wine & Proton: die drei Dinge, die wirklich zählen

GameMode schaltet während des Spiels temporär auf Performance-Prioritäten, MangoHud zeigt, ob überhaupt etwas ankommt, Esync/Fsync entlasten die Synchronisation zwischen Windows- und Linux-Threads.

sudo pacman -S gamemode lib32-gamemode mangohud lib32-mangohud goverlay sudo systemctl enable --now gamemoded # Esync/Fsync global setzen – environment.d statt .bashrc, # damit es auch für Steam/Lutris ohne interaktive Shell greift mkdir -p ~/.config/environment.d printf 'WINEESYNC=1\nWINEFSYNC=1\n' > ~/.config/environment.d/wine.conf

Startoption pro Spiel in Steam (Eigenschaften → Startoptionen):

gamemoderun mangohud %command%
Ein Limiter reicht

Wer mit MangoHud ein FPS-Limit setzt, sollte das In-Game-Limit ausschalten. Zwei Limiter mit leicht unterschiedlichem Zielwert erzeugen unruhige Frametimes, die dann fälschlich anderen Ursachen zugeschrieben werden.

04

DXVK-Feintuning pro Spiel

DXVK liest eine dxvk.conf im selben Ordner wie die Spiel-.exe. Statt einer globalen Wundertüte an Optionen lohnt sich meist genau ein Flag – die interne Latenz-Reduzierung, die inzwischen Teil von DXVK selbst ist:

# in /dxvk.conf dxgi.enableLatencyFlex = True

dxgi.nvapiHack = False nur dann setzen, wenn ein NVAPI-Workaround (z. B. für DLSS-Erkennung) Probleme macht – der Standardwert True ist für die meisten Spiele richtig.

05

Netzwerk: BBR als Congestion-Control

Senkt Latenzspitzen bei Downloads und Matchmaking-Verbindungen, ist unproblematisch und auf den meisten modernen Kerneln bereits als Modul vorhanden:

sudo tee /etc/sysctl.d/99-gaming.conf >/dev/null <<'EOF' net.core.default_qdisc = fq net.ipv4.tcp_congestion_control = bbr net.ipv4.tcp_fastopen = 3 EOF sudo sysctl --system # Kontrolle: sollte "bbr" ausgeben sysctl net.ipv4.tcp_congestion_control
06

Firewall: Ports automatisch freigeben

Statt jeden Port für jeden Launcher von Hand zu suchen, erkennt dieses Skript installierte Launcher (Steam, Battle.net, Epic, Xbox, Star Citizen) und öffnet nur deren offizielle Portlisten über UFW.

curl -O https://ts.lutti-multigaming.de/guides/gaming-tuning/gaming-ports.sh chmod +x gaming-ports.sh # Nur anzeigen, welche Ports eine Plattform braucht ./gaming-ports.sh --ports steam # Eine Plattform gezielt freigeben ./gaming-ports.sh --import starcitizen # Automatische Erkennung + volles Setup in einem Schritt ./gaming-ports.sh --full-auto
Vor --full-auto lesen

Der Befehl setzt ufw default deny incoming und aktiviert UFW. Wer schon eigene UFW-Regeln hat (z. B. für SSH von außerhalb), vorher mit sudo ufw status numbered prüfen, was aktuell offen ist.

!

Fallstricke aus alten Tuning-Skripten

  • grubby existiert nicht. Viele ältere Anleitungen setzen Kernel-Parameter mit grubby --update-kernel=ALL – auf Arch/CachyOS ist das Tool schlicht nicht installiert. Kernel-Parameter gehören in /etc/default/grub (GRUB_CMDLINE_LINUX_DEFAULT) gefolgt von sudo grub-mkconfig -o /boot/grub/grub.cfg, oder komfortabler über einen Kernel-Manager.
  • Bluetooth/CUPS pauschal deaktivieren. Steht in manchen „Aufräum"-Skripten als Performance-Tipp. Wer einen Controller per Bluetooth koppelt oder gelegentlich druckt, verliert damit ungefragt eine Funktion – nur deaktivieren, was man wirklich nicht braucht.
  • Governor-Schleife gegen power-profiles-daemon. Siehe Schritt 2 – zwei Verwalter für dieselbe Einstellung ist Zeitverschwendung.
  • Mitigations doppelt oder über den falschen Mechanismus setzen. cat /proc/cmdline zeigt, was aktuell aktiv ist – vor jeder erneuten Änderung erst prüfen, ob sie überhaupt nötig ist.
  • Skripte, die stumpf alles installieren. Ein Skript ohne Prüfung des Ist-Zustands installiert und überschreibt Konfiguration, auch wenn sie schon passend gesetzt ist. Vor jedem Lauf kurz gegenlesen, was er tatsächlich tut, statt ihn blind mit sudo auszuführen.