Nicht geeignet: Wenn Sie aus der Animgraph-2-Ankündigung allein eine konkrete Bandbreitenersparnis oder Spielerzahl ableiten möchten. Valve nennt dafür keine übertragbare Kennzahl.
Ändern Sie Ihre Bandbreitenwahl nicht allein deshalb, weil Animgraph 2 geringeren animationsbezogenen Netzwerkaufwand erwähnt. Messen Sie zuerst die Auslastung Ihres konkreten Spielmodus und die zeitgleichen ausgehenden Spitzen; erst dann sollten Sie einen Tarif beibehalten oder neu bewerten.
Dieser Beitrag ist für Sie, wenn Sie einen CS2-Community-Server betreiben und eine Leitung planen oder erweitern.
Auch bei einem Umzug von einem anderen Host erhalten Sie ein Verfahren für Messungen vor dem Start.
Verwalten Sie mehrere Spielserver, können Sie damit Einzelserverwerte von der gleichzeitigen Gesamtauslastung unterscheiden.
Zuletzt aktualisiert am 01.11.2026; geprüft anhand der CS2-Mitteilungen von Valve, der offiziellen Animgraph-2-Beta-Mitteilung, der CS2-Aktivitätsübersicht von SteamDB und der aktuellen Produktübersicht von OSFP Cloud.
Animgraph 2 und Community-Server-Bandbreite sind nicht dasselbe
Valve beschrieb Animgraph 2 in der Beta-Mitteilung vom 01.04.2026 als Änderung, die unter anderem den animationsbezogenen CPU- und Netzwerkaufwand verringert. Die Aktualisierung vom 24.04.2026 ist ebenfalls für den offiziellen Änderungsstand relevant. In den verlinkten offiziellen Informationen steht jedoch keine prozentuale Einsparung, die sich direkt auf die ausgehende Bandbreite eines Community-Servers oder eine bestimmte Spielerzahl übertragen ließe. Prüfen Sie die Aussagen im offiziellen Beta-Hinweis und in den CS2-Updates von Valve.
Das ist wichtig, weil drei Dinge häufig vermischt werden: der Netzwerkaufwand für animationsbezogene Daten, der gesamte Verkehr zwischen Server und Clients sowie die wahrgenommene Verbindung eines Spielers. Ein Spieler kann Latenz, Paketverluste oder Ruckler erleben, obwohl die Leitung des Servers nicht ausgelastet ist. Umgekehrt kann ein Server eine hohe ausgehende Datenrate aufweisen, ohne dass alle Clients dieselbe Netzwerkqualität haben. Routing, Paketverluste, Serverlast und die Leitung des jeweiligen Spielers sind eigenständige Faktoren.
Bedeutet die Animgraph-2-Änderung automatisch, dass ein CS2-Server weniger Bandbreite benötigt? Nein. Die offizielle Beschreibung bestätigt eine Änderung am animationsbezogenen Aufwand, aber keine belastbare Reduktion der für die Beschaffung relevanten Serverbandbreite. Eine Verringerung ist für Ihre konkrete Konfiguration erst dann ein Planungswert, wenn sie sich in vergleichbaren Messungen zeigt.
Auch die Aktivitätsdaten von CS2 sind kein Bandbreitenrechner: Die SteamDB-Übersicht zu CS2 kann belegen, dass das Spiel weiterhin Aktivität aufweist. Daraus folgt weder eine bestimmte Nachfrage nach Community-Servern noch eine benötigte Leitungskapazität. Ebenso belegt eine Diskussion auf Reddit zur Bandbreite und AG2 nur, dass Nutzer die Frage diskutieren; sie ist kein technischer Nachweis für eine Einsparung.
Erster Schritt: Messbedingungen festhalten, bevor Sie Werte vergleichen
Eine Messung ist nur aussagekräftig, wenn Sie wissen, unter welchen Bedingungen sie entstanden ist. Vermischen Sie daher nicht verschiedene Karten, Spielmodi, Plugin-Sätze oder Serverversionen zu einer vermeintlich allgemeinen Referenz. Schon ein Wechsel der Konfiguration kann dazu führen, dass zwei Messreihen nicht mehr dieselbe Last abbilden.
Halten Sie vor der Messung mindestens diese Angaben fest:
- installierte CS2-Serverversion und Zeitpunkt der Aktualisierung;
- Spielmodus, Karte und verwendete Plugins oder serverseitige Erweiterungen;
- Verlauf der gleichzeitig verbundenen Clients, soweit Ihre Serverprotokolle ihn erfassen;
- Start und Ende des Messfensters sowie die verwendete Zeitzone;
- weitere Prozesse und Spielserver, die auf demselben Host Netzwerkverkehr erzeugen.
Verwenden Sie diese Angaben als Bedingungen für eine spätere Wiederholung, nicht als Grundlage für eine behauptete allgemeine Kapazität. Ein Messwert aus einem bestimmten Modus sagt nicht automatisch etwas über eine andere Karte, ein Turnier, eine Plugin-Konfiguration oder einen anderen Community-Server aus.
Welche Daten sollte ich bei einem Umzug eines CS2-Servers vergleichen? Vergleichen Sie dieselbe Version, denselben Modus und möglichst ähnliche Auslastungsphasen. Notieren Sie außerdem, ob während des Messfensters Updates, administrative Verbindungen oder weitere Dienste auf dem Host aktiv waren. Wenn sich diese Bedingungen unterscheiden, markieren Sie die Messung als nur eingeschränkt vergleichbar, statt den Unterschied vorschnell Animgraph 2 zuzuschreiben.
Zweiter Schritt: Ein- und Ausgang getrennt erfassen
Für die Bandbreitenplanung ist der ausgehende Verkehr besonders wichtig, weil Serverdaten zu den Clients übertragen werden. Erfassen Sie trotzdem beide Richtungen: Eingehender Verkehr kann ebenfalls relevant sein, und eine hohe Gesamtnutzung lässt sich ohne Richtungstrennung nur schwer einordnen.
Unter Linux liefern die Schnittstellenzähler des Kernels kumulierte Werte. Die Kernel-Dokumentation beschreibt die verfügbaren Netzwerkstatistiken; RFC 2863 definiert unter anderem Zähler für ausgehende Oktette an einer Schnittstelle. Diese Zähler erfassen den Verkehr der Netzwerkschnittstelle, nicht automatisch nur den Prozess des CS2-Servers. Bei mehreren Diensten auf einem Host müssen Sie deshalb weitere Messpunkte zur Abgrenzung verwenden.
Ein einfacher Vergleich zweier Zählerstände kann so aussehen:
IFACE="ens3"
date -u
cat "/sys/class/net/$IFACE/statistics/rx_bytes"
cat "/sys/class/net/$IFACE/statistics/tx_bytes"
sleep "$MESSINTERVALL"
date -u
cat "/sys/class/net/$IFACE/statistics/rx_bytes"
cat "/sys/class/net/$IFACE/statistics/tx_bytes"
Legen Sie MESSINTERVALL als feste, dokumentierte Dauer für Ihre Messreihe fest. Berechnen Sie für jede Richtung die Differenz der Byte-Zähler zwischen den beiden Ablesungen. Teilen Sie diese Differenz durch die verstrichene Zeit, um Bytes pro Sekunde zu erhalten; für Bit pro Sekunde multiplizieren Sie das Ergebnis mit acht. Verwenden Sie für den Vergleich stets dieselbe Einheit und verwechseln Sie Megabit pro Sekunde nicht mit Megabyte pro Sekunde.
Ein möglicher, bewusst schematischer Mitschrieb sieht so aus:
Zeitpunkt (UTC) | Schnittstelle | RX-Zähler | TX-Zähler | Modus | Online-Verlauf
Start | ens3 | RX_START | TX_START | ... | ...
Ende | ens3 | RX_ENDE | TX_ENDE | ... | ...
RX_START, TX_START, RX_ENDE und TX_ENDE sind Platzhalter, keine Messergebnisse. Prüfen Sie außerdem, ob die Schnittstelle oder der Host während des Fensters neu gestartet wurde: Ein Neustart oder ein geänderter Schnittstellenname kann einen einfachen Zählervergleich ungültig machen. Für längere Zeitreihen können Sie einen Monitoring-Agenten wie den in der Node-Exporter-Anleitung beschriebenen Host-Monitor verwenden. Die Kernel-Dokumentation erläutert, welche Schnittstellenwerte grundsätzlich zur Verfügung stehen.
Lastphasen getrennt bewerten, statt jede Spitze als Dauerbedarf zu behandeln
Ein einzelner Durchschnittswert verdeckt kurze Ausschläge; ein einzelner hoher Ausschlag wiederum beweist nicht, dass Ihre Leitung dauerhaft zu klein ist. Führen Sie deshalb ein Protokoll, das stabile Spielphasen, Übergänge und sonstigen Verkehr unterscheidet. Mit Regeln für ausgewählte Ports oder Dienste können Sie Zähler ergänzen; die Dokumentation zu nftables-Zählern beschreibt Zähler als Möglichkeit, Verkehr passend zu ausgewählten Regeln zu beobachten.
| Lastphase | Zu erfassende Merkmale | In die Beschaffungsentscheidung einbeziehen? |
|---|---|---|
| Laufende Spielphase | Zeitgleicher RX- und TX-Verkehr, Verlauf der verbundenen Clients, Modus und Karte | Ja: als Basis für wiederkehrende Spielzeiten, nicht als universeller Wert |
| Karten- oder Phasenwechsel | Dauer und Höhe des Ausschlags, Zeitpunkt und wiederkehrendes Muster | Ja, wenn der Ausschlag regelmäßig auftritt oder die Leitung tatsächlich begrenzt |
| Server- oder Spieldatei-Update | Datenrichtung, Umfang und zeitliche Überschneidung mit dem Spielbetrieb | Gesondert ausweisen; nur einbeziehen, wenn diese Last im geplanten Betrieb gleichzeitig auftreten soll |
| Administration und Monitoring | Zugriffs- und Überwachungsverkehr sowie zeitliche Überschneidung | Einbeziehen, wenn diese Dienste über dieselbe Schnittstelle laufen |
| Weitere Spielserver oder Dienste | Zeitgleiche Auslastung je Dienst oder Regelzähler | Für die Gesamtleitung einbeziehen; Einzelmessungen nicht unbesehen addieren |
Bei einem einzelnen Host erfassen Schnittstellenzähler den gesamten Verkehr dieser Schnittstelle. Wenn ein CS2-Server, weitere Spielserver und Verwaltungsdienste gleichzeitig laufen, kann ein hoher TX-Wert nicht ohne zusätzliche Abgrenzung einem einzelnen Dienst zugeschrieben werden. Sie können beispielsweise zeitlich passende Monitoring-Daten und Zähler aus gezielten Firewall-Regeln heranziehen. Achten Sie darauf, dass solche Regeln den zu messenden Verkehr tatsächlich erfassen; eine Regel, die nur bestimmte Ports oder Protokolle berücksichtigt, bildet nicht zwangsläufig den gesamten Netzwerkverkehr ab.
Wie rechnen Sie mehrere Community-Server zusammen? Erfassen Sie die Auslastung der gemeinsamen Schnittstelle über denselben Zeitraum, während die Server gleichzeitig betrieben werden. Wo pro Dienst Messwerte vorliegen, addieren Sie nicht einfach die jeweils höchsten Spitzen aus unterschiedlichen Zeitpunkten. Entscheidend ist die zeitgleiche Summe der Dienste. Gibt es keine getrennte Messung, kennzeichnen Sie den Hostwert als Gesamtverkehr und leiten Sie daraus keine vermeintlich präzise Einzelserverzahl ab.
Für die Hochrechnung eignet sich als Rahmen:
geplante Spitzenlast = gemessene ausgehende Spitzenrate × geplanter Reservefaktor
Der Reservefaktor ist eine von Ihnen festgelegte Planungsannahme, keine von Valve oder OSFP Cloud zugesicherte Größe. Dokumentieren Sie ihn, statt ihn als Messwert auszugeben. Wenn Sie mehrere Dienste zusammenfassen, verwenden Sie zeitgleiche Werte und notieren Sie, welche Nebenlasten im Messfenster enthalten waren.
Bandbreite beibehalten, erneut messen oder neu bewerten?
Die folgende Tabelle ist eine Entscheidungshilfe, kein Versprechen für eine bestimmte Nutzerzahl. Sie setzt voraus, dass Sie die Einheiten korrekt umgerechnet und wiederkehrende von einmaligen Lastspitzen getrennt haben.
| Beobachtung | Was sie aussagt | Nächster Schritt |
|---|---|---|
| Wiederkehrende ausgehende Spitzen liegen deutlich unter der verfügbaren Leitung und es gibt keine Hinweise auf eine Begrenzung | Die beobachteten Bedingungen sprechen nicht für eine unmittelbare Erweiterung | Bandbreite zunächst beibehalten und weitere relevante Lastphasen protokollieren |
| Eine einzelne kurze Spitze tritt bei Update, Kartenwechsel oder Wartung auf | Das Ereignis kann eine andere Verkehrsart als der laufende Spielbetrieb abbilden | Zeitfenster und Ursache prüfen; nur dann als dauerhaften Bedarf planen, wenn es regelmäßig gleichzeitig mit dem Spielbetrieb auftritt |
| Wiederkehrende Spitzen nähern sich der verfügbaren Kapazität oder der Verkehr wird sichtbar begrenzt | Die Leitung kann unter den gemessenen Bedingungen zum Engpass werden | Messreihe verlängern, Gegenmessung durchführen und eine höhere Bandbreitenoption anhand der Produktangaben prüfen |
| Mehrere Dienste laufen gleichzeitig, aber es gibt nur eine ungetrennte Hostmessung | Der Anteil des CS2-Servers ist nicht zuverlässig zuzuordnen | Gesamtlast als solche bewerten oder Dienste mit passenden Messpunkten getrennt erfassen |
| Messwerte stammen aus unterschiedlichen Versionen, Modi oder Zeiträumen | Der Vergleich kann Änderungen an mehreren Faktoren vermischen | Vergleich unter dokumentierten, möglichst gleichen Bedingungen wiederholen |
Welche Daten sollten Sie für eine Bandbreitenschätzung verwenden? Verwenden Sie die gemessene ausgehende Spitzenrate in einer festgehaltenen Zeiteinheit, die Länge des Messfensters, den Online-Verlauf und die Lastphase. Ergänzen Sie den geplanten Reservefaktor ausdrücklich als eigene Annahme. So bleibt Ihre Schätzung nachvollziehbar, ohne aus einer Spielerzahl oder einem Valve-Hinweis eine nicht belegte Bandbreitengarantie zu machen.
Auf der Produktübersicht von OSFP Cloud sind die angebotenen Bandbreitenoptionen und die dazugehörigen Tarifbedingungen zu prüfen. Die dort aufgeführten Stufen umfassen 250 Mbit/s, 1 Gbit/s und 2 Gbit/s; für alle drei wird unbegrenztes Datenvolumen ausgewiesen. Eine unlimitierte Datenmenge bedeutet jedoch nicht, dass die Anschlusskapazität unbegrenzt ist: Die gewählte Bandbreitenstufe bleibt für die zeitgleiche Übertragung relevant. Prüfen Sie vor einer Bestellung die aktuelle Produktdarstellung, statt Preise oder Verfügbarkeit aus einem älteren Artikel zu übernehmen.
Für die Überwachung und den administrativen Zugriff sollten Sie außerdem festhalten, welche Schnittstelle und welches System Sie tatsächlich verwenden. Hinweise zum Rahmen der angebotenen Leistungen finden Sie in den Leistungsbedingungen von OSFP Cloud. Diese Informationen ersetzen weder Ihre Messung noch die Prüfung der konkreten Tarifdetails.
Nach einem Umzug mit derselben Methode gegenprüfen
Eine Migration ist ein guter Zeitpunkt, die Ausgangswerte erneut aufzunehmen, aber kein Grund, verschiedene Messbedingungen als direkten Vorher-nachher-Beweis zu behandeln. Halten Sie auf dem alten und dem neuen Host dieselbe Serverversion, denselben Spielmodus und möglichst vergleichbare Karten- und Onlinephasen fest. Erfassen Sie außerdem die gleichzeitig laufenden Anwendungen, denn andere Dienste können die gemessene Gesamtlast verändern.
Verwenden Sie für die Abnahme ein Protokoll mit diesen Feldern:
- Datum und Messzeitraum in UTC;
- Serverversion, Modus, Karte und relevante Plugins;
- Verlauf der verbundenen Clients;
- Netzwerkschnittstelle und verwendete Zähler oder Monitoring-Methode;
- Ein- und Ausgangswerte mit Einheit und Zeitfenster;
- andere aktive Dienste und besondere Ereignisse wie Updates;
- festgelegte Reserveannahme und daraus abgeleitete Entscheidung.
Vergleichen Sie nicht nur die höchste Zahl. Prüfen Sie, ob die Spitzen wiederkehren, ob sie mit einer bestimmten Phase zusammenfallen und ob die Leitung tatsächlich ausgelastet oder begrenzt war. Eine einzelne Stichprobe repräsentiert nicht automatisch alle Karten, Veranstaltungen oder Community-Server-Modi. Wenn Valve künftig eine konkrete, für Server messbare Änderung des Netzwerkverhaltens veröffentlicht, sollten Sie die Vergleichsmethode und Ihre Schlussfolgerung anhand dieser offiziellen Angaben neu prüfen.
Wenn Sie derzeit eine gemeinsam genutzte VPS-Umgebung verwenden, können geteilte CPU-Ressourcen, eingeschränkte Kontrolle über die Host-Netzwerkmessung und eine nicht immer transparente Trennung zwischen Tarifkapazität und tatsächlicher Gesamtlast die Diagnose erschweren. Eine dedizierte AMD-Maschine ist dagegen vor allem dann sinnvoll, wenn Sie dauerhaft mehrere Dienste betreiben und die Ressourcenzuordnung selbst kontrollieren müssen; sie macht eine sorgfältige Bandbreitenmessung aber nicht überflüssig und ist für kurzzeitige Tests oder sehr geringe Last nicht automatisch wirtschaftlicher.
Erfassen Sie daher zuerst die ausgehenden Spitzen Ihres eigenen Betriebs und gleichen Sie sie anschließend mit den aktuell verfügbaren Optionen ab. Wenn eine dauerhaft laufende Community-Umgebung eine eigenständige Maschine rechtfertigt, prüfen Sie die Bandbreiten- und Tarifangaben von OSFP Cloud direkt in der Produktübersicht; die Entscheidung sollte aus Ihren Messwerten folgen, nicht aus einer vermuteten AG2-Einsparung.
Planen Sie die Bandbreite Ihres CS2-Servers neu
Mit OSFP Cloud nutzen Sie einen vollständigen physischen Server mit EPYC 7543P und 32 Kernen in Tokio.
ab $462 / Monat