stadiongaming.eu

CS2-Profis: Bei 360 Hz hört das Hz-Rennen auf, sich zu lohnen - und die Frame-Mathematik stimmt zu

Zwei Counter-Strike-2-Spieler von Luminosity sagten PC Gamer, dass über 360 Hz die Gewinne kleiner und persönlicher werden - und dass die meisten PCs ein 600-Hz-Panel ohnehin nicht füttern können. Rene rechnet nach und erklärt, warum der Flaschenhals wahrscheinlich nicht der Monitor ist.

Rene Sjeverac

Wednesday, September 23, 2026

CS2-Profis: Bei 360 Hz hört das Hz-Rennen auf, sich zu lohnen - und die Frame-Mathematik stimmt zu

Jeder Monitor-Launch dieses Jahr brachte eine größere Zahl auf der Verpackung. 480. 500. 600 Hz. Und jedes Mal landet dieselbe Frage in meinen DMs: Brauche ich das, um keine Duelle mehr zu verlieren? Jetzt haben sich zwei Leute geäußert, die fürs Gewinnen dieser Duelle bezahlt werden, und die Antwort ist die, die ich schon länger gebe.

PC Gamer stellte die Frage zwei Counter-Strike-2-Spielern von Luminosity, Azuwu und yxngstxr, auf einem Logitech-G-Event in Warschau. Kurzfassung: Der Sprung auf 360 Hz ist real und man spürt ihn, sobald man dort ist, aber darüber werden die Gewinne kleiner und persönlicher, und beide wiesen auf das offensichtliche Problem hin, dass fast kein PC in einem echten Match tatsächlich 600 Bilder pro Sekunde liefert. Die Seite hatte schon zuvor argumentiert, 360 Hz sei der Sweet Spot für kompetitive Shooter; die Profis widersprachen nicht.

Mich überrascht das nicht, denn die Mathematik schreit das seit Jahren. Die Frame Time bei 240 Hz liegt bei etwa 4,2 ms. Bei 360 Hz sind es 2,8 ms. Bei 480 Hz 2,1 ms und bei 600 Hz 1,7 ms. Von 240 auf 360 gewinnt man also grob 1,4 ms pro Frame. Von 360 auf 600 sind es 1,1 ms - und das nur, wenn der Rechner konstante 600 fps liefert, was in CS2 mit der aktuellen Engine eine Top-CPU, getunten Speicher und eine Map bedeutet, die sich benimmt. Fällt man auf einem 600-Hz-Panel auf 400 fps, zahlt man für Spielraum, den man nicht nutzen kann.

Wo sich die Millisekunden wirklich verstecken

Hier ist, was eine 600-Hz-Kiste nicht reparieren kann. Der Mausklick muss ein USB-Polling-Fenster, das Input-Sampling des Spiels, die Render-Queue, die GPU und schließlich die Pixel-Reaktionszeit des Panels überleben, bevor er als sichtbarer Schuss auf dem Bildschirm landet. Auf einem gut abgestimmten System liegt diese ganze Kette irgendwo im niedrigen zweistelligen Millisekundenbereich. Eine weitere Millisekunde vom Anzeigeintervall abzuschneiden ist ein einstelliger Prozentsatz dieser Kette. Eine schlechte Config dagegen - Vsync, das sich einschleicht, eine volle Render-Queue, eine Hintergrund-App, die einen Kern frisst - kann ein Vielfaches davon draufpacken.

Deshalb sage ich den Leuten immer wieder, zuerst das Langweilige zu fixen. Frames cappen, damit das Pacing flach statt zackig ist. Jedes Overlay ausschalten. Prüfen, ob das Panel unter Windows wirklich mit der beworbenen Bildwiederholrate läuft, denn man wäre erstaunt, wie viele 360-Hz-Monitore ab Werk auf 144 stehen. Dann die 1% Lows loggen, denn ein 360-Hz-Panel, das von einem Spiel gefüttert wird, das zwischen 250 und 500 fps springt, sieht schlechter aus als ein 240-Hz-Panel mit festen 240.

Es gibt ein ehrliches Argument für die sehr hohen Bildwiederholraten: Bewegungsschärfe. Selbst wenn die fps die Rate nicht erreichen, verschmiert ein schnelleres Panel mit gutem Overdrive bei Flicks weniger. Aber das ist eine Pixel-Response-Geschichte, keine Refresh-Rate-Geschichte, und die Spieler, mit denen PC Gamer sprach, waren klar: Alles über 360 ist marginal und hängt vom Einzelnen ab.

Meine Meinung, nachdem ich viele Setups für Leute abgestimmt habe, die überzeugt waren, der Monitor sei ihr Problem: Wer auf 144 oder 165 sitzt, für den ist ein 240- oder 360-Hz-Panel das spürbarste Upgrade überhaupt. Wer schon auf 360 ist und den Trade trotzdem verliert, bei dem ist das Display nicht der Flaschenhals. Man selbst ist es. Oder die Config. Und das meine ich freundlich, denn meine war es auch.

Bild: Notdjey / CC BY 2.0, source: https://commons.wikimedia.org/wiki/File:Gaming_computers_(1).jpg