Hardware- & Netzwerkanforderungen für Source-Engine-Server

Die Source Engine ist eine 3D-Videospiel-Engine, die von Valve entwickelt wurde. Die Source Engine ist bekannt für ihre Fortschritte in Physik, KI und Grafik, die die Spiele für ihre Zeit realistisch wirken ließen, während sie gleichzeitig auf älterer, weniger leistungsfähiger Hardware skalierbar blieb. Source-Engine-Server sind gehostete Spieldienste, die es Spielern ermöglichen, sich zu verbinden und gemeinsam in der Welt des Servers zu spielen. Server in der Source Engine können mit Mods angepasst werden, was zu einem einzigartigen und oft unterhaltsamen Spielerlebnis für alle mit dem Server verbundenen Spieler führt.

Spiele, die auf der Source Engine laufen, umfassen Team Fortress 2, Counter-Strike: Source, Garry's Mod und viele weitere!

Eine häufig gestellte Frage ist, welche Hardware- und Netzwerkanforderungen für den Betrieb eines Source-Engine-Servers bestehen und wie sich diese im Vergleich zu Servern in anderen Spielen wie Minecraft und Rust verhalten. Die Antwort auf diese Frage lautet: es kommt wirklich darauf an.

Während Source-Engine-Server im Vergleich zu anderen Spielen wie Minecraft und Rust deutlich weniger RAM verbrauchen, sind sie größtenteils single-threaded. Das bedeutet, dass ein Prozessor mit niedriger Kernanzahl, aber hoher Single-Thread-Leistung bei Source-Engine-Servern besser abschneidet als ein Prozessor mit vielen Kernen, aber niedriger Single-Thread-Leistung. Dies gilt besonders, wenn du einen ressourcenintensiven Gamemode hosten möchtest oder viele Spieler gleichzeitig mit dem Server verbunden sein sollen.

Hier ist trotzdem eine Liste zusätzlicher Faktoren, die du bei der Wahl deiner Hardware- und Netzwerkanforderungen berücksichtigen solltest.

• Die maximale Anzahl an Spielern, die gleichzeitig mit dem Server verbunden sind und spielen.
• Der Gamemode, die Anzahl der Mods und die Art der Maps, die der Server verwendet.
• Die Tickrate des Servers.
• Die leistungsbezogenen ConVar-Werte des Servers.

Wenn du die absolut beste Leistung möchtest und das nötige Geld dafür hast, empfehle ich persönlich, nach einem Server mit einer CPU aus einer Liste wie den am höchsten bewerteten CPU-Benchmarks für Single-Thread-Leistung von Passmark zu suchen.

Gleichzeitige Spieler

Je mehr Spieler gleichzeitig mit dem Server verbunden sind, desto mehr Netzwerkdaten werden zwischen jedem Client ausgetauscht, und typischerweise passiert auch mehr im Spiel und auf dem Server selbst, was zu einer höheren CPU-Auslastung führt.

Es gibt keine allgemeine Richtlinie oder Faustregel für Single-Thread-Geschwindigkeiten und Spielerzahlen, da es so viele andere Variablen gibt. Wenn du jedoch vorhast, viele Spieler gleichzeitig mit dem Server zu verbinden, solltest du versuchen, eine modernere CPU mit höherer Single-Thread-Leistung zu bekommen.

Gamemode, Anzahl Der Mods & Arten Von Maps

Dies sind sehr wichtige Faktoren, die bei der Bestimmung deiner Serveranforderungen berücksichtigt werden müssen. Ein Server, der beispielsweise einen Gamemode wie Deathmatch in Counter-Strike: Source ausführt, bei dem Spieler ständig aufeinander schießen, respawnen und herumlaufen, wird höchstwahrscheinlich mehr Ressourcen verbrauchen als ein Server mit einem Gamemode, bei dem Spieler nach ihrem Tod erst in der nächsten Runde respawnen.

Davon abgesehen werden Nahkampf-Maps oder Maps, die viele physikalische Props verwenden, höchstwahrscheinlich mehr CPU-Leistung beanspruchen als eine größere und offenere Map.

Die Tickrate Des Servers

Die Tickrate gibt an, wie oft der Server das Spiel simuliert. Standardmäßig ist die Tickrate eines Servers auf 66,66... (alle 15ms) eingestellt. Dieser Wert kann über das Kommandozeilenargument -tickrate im Startbefehl des Servers geändert werden, sofern das Spiel oder ein Mod es Serveradministratoren erlaubt, ihn anzupassen.

Je höher die Tickrate des Servers ist, desto mehr CPU-Leistung und Bandbreite werden benötigt. Dies führt außerdem dazu, dass der Server mehr Updates an Clients sendet und von ihnen empfängt, was die Client-Latenz, die Trefferregistrierung und mehr verbessert!

Es gibt viele Server in Garry's Mod, die bis zu 128 gleichzeitig verbundene Spieler hosten. Sie schaffen das, weil sie mit einer niedrigen Tickrate wie 33 oder 22 laufen, was in den meisten Fällen niedrig genug ist, damit die CPU die allgemeine Serverlast bewältigen kann (natürlich abhängig vom jeweiligen Server).

Die Leistungsbezogenen ConVar-Werte Des Servers

Es gibt einige ConVars, die die Serverleistung betreffen und die du auf dem Server anpassen kannst, um zu beeinflussen, wie viel CPU-Leistung und Bandbreite dein Server verbraucht. Diese Einstellungen können sich zudem auf die Latenz des Clients, die Anzahl der Paketverluste, Choke und mehr auswirken.

Hier ist eine Liste einiger leistungsbezogener ConVars, die sich meiner Erfahrung nach als am nützlichsten erwiesen haben.

• sv_maxrate - Die maximale Bandbreitenrate des Clients (eingehend und ausgehend), die pro Sekunde auf dem Server in "Bytes" erlaubt ist. Setzt man dies auf 0, bedeutet das unbegrenzt und wird empfohlen, wenn du die entsprechende Netzwerk- und Hardwarekapazität hast.
• sv_minrate - Die minimale Bandbreitenrate des Clients (eingehend und ausgehend), die pro Sekunde auf dem Server in "Bytes" erlaubt ist.
• sv_maxupdaterate - Die maximale Anzahl an Update-Paketen pro Sekunde, die der Server an einen Client senden kann. Dies entspricht typischerweise dem Tickrate-Wert deines Servers. In manchen Fällen kann er jedoch gesenkt werden, um die CPU zu entlasten oder die Bandbreitennutzung zu verringern.
• sv_minupdaterate - Die minimale Anzahl an Update-Paketen pro Sekunde, die der Server an den Client senden kann. Dies liegt typischerweise irgendwo zwischen 0 und der Hälfte des Tickrate-Werts deines Servers (z. B. 33).
• sv_maxcmdrate - Die maximale Anzahl an Command-Paketen pro Sekunde, die der Server an den Client senden kann. Dies entspricht typischerweise dem Tickrate-Wert deines Servers. In manchen Fällen kann er jedoch gesenkt werden, um die CPU zu entlasten oder die Bandbreitennutzung zu verringern.
• sv_mincmdrate - Die minimale Anzahl an Command-Paketen pro Sekunde, die der Server an den Client senden kann. Dies liegt typischerweise irgendwo zwischen 0 und der Hälfte des Tickrate-Werts deines Servers (z. B. 33).
• net_splitpacket_maxrate - Die maximale Anzahl an Bytes pro Sekunde, mit der der Server geteilte Pakete an den Client senden kann. Setzt man diesen Wert höher, etwa auf 128000, kann das in Situationen helfen, in denen Choke auftritt, weil auf einmal viele Netzwerkdaten übertragen werden.
• net_maxcleartime - Die maximale Zeit in Sekunden, die der Server pro Tick mit der Verarbeitung und dem Senden von Netzwerkdaten verbringt. Setzt man diesen Wert niedrig, etwa auf 0.001, kann das in bestimmten Situationen Choke reduzieren, erfordert aber mehr CPU-Leistung.
• sv_parallel_sendsnapshot - Wenn auf 1 gesetzt, erlaubt dies dem Server, einen separaten Thread zu nutzen, um die Spielzustands-Snapshots für jeden Client vorzubereiten. Dies kann die Serverleistung in Umgebungen mit vielen Spielern deutlich verbessern.

Ich empfehle, dich über Source Multiplayer Networking zu informieren, um besser zu verstehen, worauf diese Werte gesetzt werden sollten. Ich fand dieses Thema von NFOservers.com ebenfalls extrem informativ und hilfreich!

Wenn du einen dedizierten Hosting-Anbieter nutzt, hast du höchstwahrscheinlich die Netzwerkkapazität, um diese ConVar-Werte auf hohe Werte/unbegrenzt zu setzen. In diesem Fall sollten die folgenden Werte in den meisten Fällen funktionieren.

sv_maxrate 0
sv_minrate 75000
sv_maxupdaterate 66
sv_minupdaterate 20
sv_maxcmdrate 66
sv_mincmdrate 20
net_splitpacket_maxrate 128000
net_maxcleartime 0.001
sv_parallel_sendsnapshot 1

Falls du dir immer noch unsicher bist, auf welche Werte du diese leistungsbezogenen ConVars setzen solltest, empfehle ich die Verwendung eines Tools wie diesem, um die Werte zu berechnen. Trotzdem wird empfohlen, einen Netzwerkgeschwindigkeitstest mit Tools wie SpeedTest.net oder CloudFlare durchzuführen, um die Upload- und Download-Geschwindigkeiten deines Servers zu ermitteln. Diese Netzwerkgeschwindigkeiten spielen eine große Rolle dabei, wie viele Spieler du gleichzeitig mit dem Server verbinden kannst, bevor netzwerkbezogene Probleme wie Paketverlust auftreten (besonders deine Upload-Geschwindigkeit, da sie angibt, wie viel Bandbreite du gleichzeitig an alle Spieler über das Internet senden kannst).

Serverleistung überwachen

Das beste ingame Tool, um die Serverleistung in Source-Engine-Spielen zu überwachen, ist der integrierte Net Graph. Du kannst den Net Graph anzeigen, indem du den Wert von net_graph in der Entwicklerkonsole von 0 auf 4 änderst.

Dieses Tool zeigt die Menge an Bandbreite an, die du vom Server, mit dem du verbunden bist, sendest und empfängst, die FPS des Servers, die Anzahl der Updates, die du und der Server senden/empfangen, und mehr!

Eine ausführlichere Erklärung des Net Graphs findest du hier.

Hier sind einige Informationen von der zuvor verlinkten Wiki-Seite:

Area 1

Dieser Bereich ist die Legende für die im Payload-Abschnitt des Graphen verwendeten Farben. Wenn ein Teil der Payload eintrifft, aber in keinen der vordefinierten Buckets passt, wird er im freien Bereich zwischen der letzten Farbe und dem kleinen weißen Punkt dargestellt, der die volle Paketgröße repräsentiert (siehe Markierung a im Bild)

Area 2

Bei Paketen, die größer als 300 Bytes sind und sich im 95. Perzentil befinden, wird die Größe des Pakets als Text am oberen Rand des Payload-Bereichs angezeigt (siehe Markierung 2). Beachte, dass die Orange-Box-Technik Komprimierung auf die Pakete anwendet, die im net_graph-Payload angezeigten Größen jedoch auf der dekomprimierten Payload-Größe basieren.

Area 3

Die FPS der lokalen Verbindung und der Round-Trip-Ping zum Server werden in Bereich 3 angezeigt.

Area 4

Dieser Bereich zeigt die aktuelle Bandbreitennutzung an. In/out zeigen die Größe in Bytes des letzten eingehenden und ausgehenden Pakets. k/s zeigt die zuletzt beobachteten Kilobytes pro Sekunde (gleitender Durchschnitt) in jede Richtung.

Area 5

Dieser Bereich zeigt die Leistung des Servers, mit dem der Client verbunden ist. Das sv-Tag zeigt die FPS des Servers zum Zeitpunkt des letzten an den Client übermittelten Netzwerk-Updates. Das var zeigt die Standardabweichung der Frametime des Servers (wobei server fps = 1.0 / frametime) über die letzten 50 vom Server aufgezeichneten Frames. Wenn die Framerate des Servers unter 20 fps liegt, wird diese Zeile gelb dargestellt. Wenn die Framerate des Servers unter 10 fps liegt, wird diese Zeile rot dargestellt.

Area 6

Die lerp-Anzeige zeigt die Anzahl der Millisekunden Interpolation, die vom Client verwendet werden. Einige Anmerkungen zum Wert von lerp folgen unten.

Area 7

Dieser Bereich zeigt die aktuelle cl_updaterate-Einstellung des Nutzers, die tatsächliche Anzahl an Updates pro Sekunde, die tatsächlich vom Server empfangen wurden, die tatsächliche Anzahl an Paketen pro Sekunde, die an den Server gesendet wurden, sowie die cl_cmdrate-Einstellung des Nutzers (die gewünschte Anzahl an Paketen pro Sekunde, die der Nutzer an den Server senden möchte).

Area 8

Wenn net_graphshowlatency auf 1 gesetzt ist, zeigt dieser Bereich eine historische Ansicht der Latenz der Verbindung. Die Höhe (angezeigt durch Markierung d) entspricht der net_graphmsecs-Zeit (tatsächlich gibt es oben etwas zusätzlichen Platz nach net_graphmsecs, damit die Textfelder hineinpassen). Rote vertikale Linien zeigen verlorene Pakete vom Server zum Client an. Wenn der Graph eine gelbe Markierung anzeigt (wie bei Markierung c), bedeutet das, dass der Server ein oder mehrere Pakete zurückhalten musste, bevor er dem Client ein Update senden konnte.

Area 9

Wenn net_graphshowinterp auf 1 gesetzt ist, zeigt dieser Bereich für jeden Client-Frame, wie viel Interpolation benötigt wurde. Wenn zwischen Paketen eine große Lücke besteht (Paketverlust, zu niedrige Server-Framerate usw.), hat der Client nicht genügend Daten für die Interpolation und beginnt zu extrapolieren. Die Extrapolation wird als orangefarbene Balken dargestellt, die über die weiße Linie hinausragen (ein Beispiel für eine Extrapolationsphase ist direkt links von der 9er-Markierung zu sehen). Zusätzlich zeigt das unterste Pixel an, ob in diesem Renderframe ein CUserCmd-Paket (usercmd) gesendet wurde oder ob es vom Client zurückgehalten und aufgrund der cl_cmdrate-Einstellung des Nutzers gesammelt wurde.

Dedicated Hosting VS LAN-Server

Auch wenn du theoretisch einen öffentlichen Server über dein Heimnetzwerk (LAN) hosten kannst, wird dies nicht empfohlen. Stattdessen solltest du einen Server bei einem dedizierten Hosting-Anbieter erwerben.

Auch wenn die abonnementbasierten Gebühren, die häufig mit dediziertem Hosting einhergehen, oft als großer Nachteil angesehen werden, gibt es folgende Gründe, dediziertes Hosting zu nutzen:

• Besserer Schutz vor (D)DoS-Angriffen durch höhere Netzwerkkapazität und speziell dafür entwickelte Abwehrsysteme.
• Besseres Client-Routing und geringere Latenz.
• Höhere Stabilität (z. B. fällt der Server bei einem Stromausfall zu Hause nicht offline).

Zusätzlich hier ein paar Gründe, deinen Server nicht zu Hause zu hosten.

• Manche Internetanbieter untersagen das Hosten eines öffentlichen Spieleservers über dein Heimnetzwerk.
• Höhere Strom- und Netzwerkkosten zu Hause, abhängig davon, wie viele Server betrieben werden, wie hoch die Serverlast ist, welcher Prozessor verwendet wird usw.

Siehe auch

• NFOservers - Anleitung zur Fehlerbehebung bei Lag in Valve-Spielen
• Valve - Source Multiplayer Networking
• Source Dedicated Server Rate Calculator 2015
• Valve - TF2 Net Graph

https://moddingcommunity.com/blog/how-to-download-run-steamcmd/

Fazit

Damit ist dieser Leitfaden/Wissensdatenbank-Artikel abgeschlossen. Du solltest nun ein besseres Verständnis davon haben, welche Hardware- und Netzwerkanforderungen für den Betrieb eines Source-Engine-Servers nötig sind.

Falls du Fragen oder Feedback zu diesem Leitfaden hast, antworte bitte im dazugehörigen Forumsthema hier! Dieser Leitfaden wird im Laufe der Zeit weiter überarbeitet und verbessert.

Tritt unserem Discord-Server bei!