De Source engine is een 3D-videogame-engine ontwikkeld door Valve. De Source engine is bekend voor zijn vooruitgang op het gebied van physics, AI en graphics, waardoor games realistisch aanvoelden voor die tijd, terwijl ze toch schaalbaar bleven op oudere, minder krachtige hardware. Source engine servers zijn gehoste gameservices waarmee spelers kunnen verbinden en samen kunnen spelen in de wereld van de server. Servers op de Source engine kunnen aangepast worden met mods, wat resulteert in een unieke en vaak leuke gameplay-ervaring voor alle spelers die verbonden zijn met de server.
Games die op de Source engine draaien zijn onder andere Team Fortress 2, Counter-Strike: Source, Garry's Mod, en nog vele anderen!
Een veelgestelde vraag is wat de hardware- en netwerkvereisten zijn voor het draaien van een Source engine server, en hoe dit zich verhoudt tot servers in andere games zoals Minecraft en Rust. Het antwoord op deze vraag is: het hangt er echt van af.
Hoewel Source engine servers veel lichter zijn op RAM-gebruik in vergelijking met andere games zoals Minecraft en Rust, zijn ze voornamelijk single-threaded. Dit betekent dat een processor met een laag aantal cores, maar hoge single-threaded prestaties, beter zal presteren dan een processor met veel cores maar lage single-threaded prestaties voor Source engine servers. Dit geldt vooral als je een intensieve game mode wilt hosten of veel spelers gelijktijdig verbonden wilt hebben met de server.
Dat gezegd hebbende, hier is een lijst met extra factoren om rekening mee te houden bij het bepalen van je hardware- en netwerkvereisten.
- Het piekaantal spelers dat gelijktijdig verbonden en aan het spelen is op de server.
- De game mode, het aantal mods, en welk type maps de server draait.
- De tickrate van de server.
- De prestatiegerelateerde ConVar waarden van de server.
Als je de absoluut beste prestaties wilt en het geld ervoor hebt, zou ik zelf aanraden om te zoeken naar een server met een CPU uit een lijst zoals de hoogst gewaardeerde CPU-benchmarks voor single-threaded prestaties van Passmark.
Gelijktijdige spelers
Hoe meer spelers er gelijktijdig verbonden zijn met de server, hoe meer netwerkdata er wordt uitgewisseld tussen elke client, en doorgaans hoe meer er gebeurt in het spel en de server zelf, wat resulteert in hoger CPU-gebruik.
Hoewel er geen algemene richtlijn of vuistregel bestaat over single-threaded snelheden en spelersaantallen omdat er zoveel andere variabelen zijn, moet je, als je van plan bent veel spelers gelijktijdig verbonden te hebben met de server, proberen een modernere CPU aan te schaffen met hogere single-threaded prestaties.
Game Mode, aantal mods & type maps
Dit zijn zeer belangrijke factoren om rekening mee te houden bij het bepalen van welke serververeisten je nodig hebt. Zo zal een server die een game mode zoals Deathmatch in Counter-Strike: Source draait, waarbij spelers voortdurend op elkaar schieten, respawnen en rondrennen, waarschijnlijk meer resources verbruiken dan een server met een game mode waarbij spelers na hun dood niet respawnen tot de volgende ronde.
Dat gezegd hebbende, maps met veel nauwe ruimtes of maps die veel gebruikmaken van physical props zullen waarschijnlijk meer CPU-kracht verbruiken dan een grotere en meer open map.
De Tickrate van de Server
De tickrate geeft aan hoe vaak de server het spel simuleert. Standaard staat de tickrate van een server ingesteld op 66.66... (elke 15ms). Deze waarde kan worden aangepast met de -tickrate command-line argument in het opstartcommando van de server, als het spel of een mod serverbeheerders toestaat deze te wijzigen.
Hoe hoger de tickrate van de server is, hoe meer CPU-kracht en bandbreedte er vereist zijn. Dit resulteert er ook in dat de server meer updates verstuurt en ontvangt naar en van clients, wat de latency van de client, hit registration, en meer verbetert!
Er zijn veel servers in Garry's Mod die tot 128 spelers gelijktijdig hosten. Ze kunnen dit bereiken omdat ze draaien op een lage tickrate waarde zoals 33 of 22, wat laag genoeg is voor de CPU om de algemene serverbelasting in de meeste gevallen aan te kunnen (afhankelijk van de server, natuurlijk).
De Performance Rate ConVar Waarden van de Server
Er zijn een aantal ConVars gerelateerd aan serverprestaties die je op de server kunt aanpassen en die invloed hebben op hoeveel CPU en bandbreedte je server verbruikt. Dat gezegd hebbende, deze instellingen kunnen invloed hebben op de latency van een client, het aantal packet loss, choke, en meer.
Hier is een lijst met een aantal prestatiegerelateerde ConVars die ik het meest nuttig heb gevonden.
sv_maxrate- De maximale bandbreedte (zowel inkomend als uitgaand) die de client per seconde op de server toegestaan krijgt, in "bytes". Dit instellen op0betekent onbeperkt en wordt aanbevolen als je de netwerk- en hardwarecapaciteit hebt.sv_minrate- De minimale bandbreedte (zowel inkomend als uitgaand) die de client per seconde op de server toegestaan krijgt, in "bytes".sv_maxupdaterate- Het maximale aantal update-pakketten per seconde dat de server naar een client kan sturen. Dit is doorgaans gelijk aan de tickrate van je server. In sommige gevallen kan dit echter verlaagd worden om minder belasting op de CPU te leggen of het bandbreedtegebruik te verlagen.sv_minupdaterate- Het minimale aantal update-pakketten per seconde dat de server naar de client kan sturen. Dit ligt doorgaans ergens tussen0en de helft van de tickrate van je server (bijv.33).sv_maxcmdrate- Het maximale aantal command-pakketten per seconde dat de server naar de client kan sturen. Dit is doorgaans gelijk aan de tickrate van je server. In sommige gevallen kan dit echter verlaagd worden om minder belasting op de CPU te leggen of het bandbreedtegebruik te verlagen.sv_mincmdrate- Het minimale aantal command-pakketten per seconde dat de server naar de client kan sturen. Dit ligt doorgaans ergens tussen0en de helft van de tickrate van je server (bijv.33).net_splitpacket_maxrate- Het maximale aantal bytes per seconde dat de server aan gesplitste pakketten naar de client kan sturen. Dit instellen op een hogere waarde zoals128000kan helpen in situaties waarbij choke optreedt doordat er veel netwerkdata tegelijk wordt verzonden.net_maxcleartime- De maximale tijd in seconden die de server besteedt aan het verwerken en verzenden van netwerkdata binnen één enkele tick. Dit instellen op een lage waarde zoals0.001kan choke in bepaalde situaties verminderen, maar vereist meer CPU-kracht.sv_parallel_sendsnapshot- Wanneer op1gezet, staat dit de server toe om een apart thread te gebruiken om game state snapshots voor elke client voor te bereiden. Dit kan de serverprestaties in omgevingen met veel spelers sterk verbeteren.
Ik raad aan om te lezen over Source Multiplayer Networking om beter te begrijpen op welke waarden deze instellingen moeten staan. Ik vond dit topic van NFOservers.com ook zeer informatief en behulpzaam!
Als je gebruikmaakt van een dedicated hostingprovider, heb je meestal genoeg netwerkcapaciteit om deze ConVar-waarden hoog of onbeperkt in te stellen. In dat geval zouden de volgende waarden in de meeste gevallen goed moeten werken.
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
Als je nog niet zeker weet op welke waarden je deze prestatiegerelateerde ConVars moet instellen, raad ik aan om een tool zoals deze te gebruiken om de waarden te berekenen. Daarnaast wordt aangeraden om een netwerksnelheidstest uit te voeren met tools zoals SpeedTest.net of CloudFlare om de upload- en downloadsnelheden van je server te achterhalen. Deze netwerksnelheden spelen een grote rol in hoeveel spelers je gelijktijdig met de server verbonden kunt hebben voordat je netwerkgerelateerde problemen zoals packet loss tegenkomt (vooral je uploadsnelheid, omdat dit aangeeft hoeveel bandbreedte je tegelijk naar alle spelers over het internet kunt verzenden).
Serverprestaties Monitoren
De beste in-game tool om de serverprestaties in Source engine-games te monitoren is de ingebouwde Net Graph. Je kunt de net graph weergeven door je net_graph-waarde in de Developer console van 0 naar 4 aan te passen.
Deze tool toont de hoeveelheid bandbreedte die je verzendt en ontvangt van de server waarmee je verbonden bent, de FPS van de server, het aantal updates dat jij en de server verzenden/ontvangen, en meer!
Een uitgebreidere uitleg van Net Graph is hier te vinden.
Hier is wat informatie van de eerder gelinkte Wiki-pagina:
![]()
Area 1
Dit gebied is de legenda voor de kleuren die worden gebruikt in het payload-gedeelte van de graph. Als een deel van de payload aankomt maar niet in een van de vooraf bepaalde buckets past, wordt het weergegeven in het lege gebied tussen de laatste kleur en het kleine witte stipje dat de volledige pakketgrootte voorstelt (zie indicator a in de afbeelding)
Area 2
Voor pakketten die groter zijn dan 300 bytes en zich in het 95e percentiel bevinden, wordt de grootte van het pakket als tekst weergegeven aan de bovenkant van het payload-gebied (zie marker 2). Merk op dat de Orange Box-technologie compressie op de pakketten toepast, maar de groottes die in de
net_graph-payload worden gerapporteerd zijn gebaseerd op de gedecomprimeerde payload-grootte.
Area 3
De frames per seconde van de lokale verbinding en de round trip ping naar de server worden in gebied 3 weergegeven.
Area 4
Dit gebied toont het huidige bandbreedtegebruik. De in/out tonen de grootte in bytes van het laatste inkomende en uitgaande pakket. De k/s toont de kilobytes per seconde (voortschrijdend gemiddelde) die recentelijk in elke richting zijn waargenomen.
Area 5
Dit gebied toont de prestaties van de server waarmee de client verbonden is. De
sv-tag toont de FPS van de server op basis van de laatste netwerkupdate die naar de client is verzonden. Devartoont de standaarddeviatie van de frametime van de server (waarbijserver fps = 1.0 / frametime) over de laatste 50 frames die door de server zijn geregistreerd. Als de framerate van de server onder 20 fps zakt, wordt deze lijn geel weergegeven. Als de framerate van de server onder 10 fps zakt, wordt deze lijn rood weergegeven.
Area 6
De
lerp-indicator toont het aantal msecs interpolatie dat door de client wordt gebruikt. Hieronder volgen enkele opmerkingen over de waarde van lerp.
Area 7
Dit gebied toont de huidige
cl_updaterate-instelling van de gebruiker, het werkelijke aantal updates per seconde dat daadwerkelijk van de server wordt ontvangen, het werkelijke aantal packets per seconde dat naar de server wordt gestuurd en decl_cmdrate-instelling van de gebruiker (dit is het gewenste aantal packets per seconde dat de gebruiker naar de server wil sturen).
Area 8
Wanneer
net_graphshowlatencyop 1 staat, toont dit gebied een historisch overzicht van de latency van de verbinding. De hoogte (aangeduid met markering d) komt overeen met denet_graphmsecs-tijd (er is bovenaan eigenlijk wat extra ruimte nanet_graphmsecszodat de tekstvelden erin passen). Rode verticale lijnen geven packets aan die van de server naar de client verloren zijn gegaan. Als de grafiek een gele markering toont (zoals bij markering c), betekent dit dat de server een of meerdere packets moest inhouden voordat er een update naar de client werd gestuurd.
Area 9
Wanneer
net_graphshowinterpop 1 staat, toont dit gebied voor elk client-frame hoeveel interpolatie er nodig was. Als er een groot gat tussen packets is (packet loss, te lage framerate van de server, enz.), heeft de client onvoldoende data voor interpolatie en begint deze te extrapoleren. De extrapolatie wordt weergegeven als oranje balken die boven de witte lijn uitsteken (een reeks extrapolatie is te zien net links van de 9-markering). Daarnaast geeft de allerlaatste pixel onderaan aan of er eenCUserCmd(usercmd) packet werd verstuurd tijdens dat render-frame, of dat deze door de client werd ingehouden en verzameld vanwege decl_cmdrate-instelling van de gebruiker.
Dedicated Hosting VS LAN Server
Hoewel je wel een publieke server op je thuisnetwerk (LAN) kunt hosten, wordt dit niet aangeraden. In plaats daarvan zou je een server moeten aanschaffen bij een dedicated hosting provider.
Hoewel de abonnementskosten die vaak bij dedicated hosting horen vaak als een groot nadeel worden gezien, zijn er redenen om toch voor dedicated hosting te kiezen, waaronder:
- Betere bescherming tegen (D)DoS-aanvallen dankzij hogere netwerkcapaciteit en mitigatiesystemen die specifiek zijn ontworpen om aanvallen af te handelen.
- Betere client-routing en latency.
- Meer stabiliteit (bijv. als er thuis een stroomstoring optreedt, gaat de server niet offline).
Daarnaast zijn hier een paar redenen om je server niet thuis te hosten.
- Sommige ISP's staan het hosten van een publieke game server op je thuisnetwerk niet toe.
- Hogere thuis-elektriciteits- en netwerkbandbreedtekosten, afhankelijk van hoeveel servers er draaien, de belasting van de server, de processor van de server, enz.
Zie Ook
- NFOservers - Valve games lag troubleshooting guide
- Valve - Source Multiplayer Networking
- Source Dedicated Server Rate Calculator 2015
- Valve - TF2 Net Graph
https://moddingcommunity.com/blog/how-to-download-run-steamcmd/
Conclusie
Dat brengt ons aan het einde van deze gids/kennisbank-topic. Je zou nu een beter begrip moeten hebben van welke hardware en netwerk je nodig hebt bij het draaien van een Source engine server.
Als je vragen of feedback hebt over deze gids, reageer dan gerust op het forumtopic hier! Deze gids zal in de loop van de tijd verder worden bijgewerkt en verbeterd.
Join onze Discord server!

