EN:Server FAQ
A small collection of frequently asked questions regarding game servers.
How important is it to run a srcds-based server with high fps?
Simple answer: it isn't at all. Since all major games have moved to the orangebox engine, the fps only have to support the tickrate. Before orangebox the server was processing incoming network packets only during the frames. Lower fps meant therefore a larger random time added to the latency of each network packet. As this random time was unknown the latency/lag compensation could not work precise. Now (since the orangebox update) network packets are recieved in a seperate thread. The fps therefore don not have any influence on the latency compensation anymore. As fps are now only used to render world snapshots ("ticks") fps higher than the tickrate are completely useless and consume only ressources. So as a matter of fact, fps higher than the tickrate actually make the server a little worse.
This fact has been thoroughly tested and confirmed by many people with various methods.
How many servers / slots can I run on this machine?
This question cannot be answered precisely for many reasons. First, the total number of slots is not the right quantity to ask for (at least not on multi-core machines), because srcds/hlds can only use one single core. So there will be some limit how many slots can be hosted per game-server. Additionally (maybe even more important) there is a limit how many servers can be run in total. Even if the slot count is very low, performance will start getting degraded if more than 2 servers are running per core.
Also the situation strongly depends on configuration. E.g. some server plugins might have a severe impact on the performance. Also the tickrate and nominal FPS will have an influence on the required ressources - but not as strong as one could believe. Reducing the FPS by a factor of 2 does not reduce the required CPU amount by the same factor by far. Reducing the tickrate will have a bigger impact. Always keep in mind that those numbers are only numbers. What matters is how the actual "feeling" is for the players.
And last but not least, running a server with a high slot-count (like 32) takes very much cpu, esp. for orangebox-based games. Make sure you have one of the fastest cpus (per core!) available on the market.
A note regarding hyper-threading: Hyper-threading splits each core into two virtual cores. Those virtual cores are not completely independent, so load on one virtual core will influence the other. This suggests turning it off if you want to squeeze the maximum out of a single core, i.e. for large servers. Only for running many small servers it might actually help. Keep in mind that binding servers to specific cores can lead to strange effects if hyper-threading is switched on (as the cores influence each other).
Also make sure your bandwidth is sufficient for the number of slots. If your server is located in a data centre and has (at least) a 100 MBit/s connection, the bandwidth will hardly be the limit. On the other hand, if you run on some home connection, it will most probably be the limiting factor.
Short answer: Simply try it out. Start with one big or two small servers per core.
Can I run hlds- and srcds-based servers on the same machine at the same time?
You can, but most likely quality will be dramatically degraded if both servers are used at the same time. It is strongly recommended not to run hlds and srcds on the same machine at the same time.
I compiled my own kernel but it does not boot (or I get a kernel panic during boot)
Well, the "trick" to avoid those kernel panics is to know which drivers you need for the boot process. The most probable problem is the HDD controller. This driver must be compiled into the kernel (not as module, i.e. make it [*] instead of [M]). Also the file system driver for your root partition must be in the kernel. All other drivers probably can be a module, because once the kernel can access the disk and the root file system it can load modules.
Virtually all Linux distributors have to use another "trick" for their default kernel, because they cannot know which driver is required (as the distribution should run on any system). They compile all drivers as modules (the kernel would be way too big if they'd compile all into the kernel) and then place all modules into a so-called inititial ram disk ("initrd", "initramfs" or so). That ram disk is loaded by the boot loader (e.g. grub) together with the kernel, so the kernel can access the modules even before it can read the root file system. But this method is more complicated in our case, because every distribution has it's own tools to create those initial ram disks.
So I recommend finding the required drivers and compiling them into the kernel. That way it will also be much easier to do kernel updates, because you don't need to create the initrd every time.
If you need help identifying the required drivers, post the output of lspci and your exact kernel version you intent to use on the srcds.com forums.
My CPU usage is too high, what can I do about it?
Linux isn't able to measure the CPU usage reliable. Also the stats rcon command outputs anything but a reliable cpu usage.
Simple reason: The linux kernel samples CPU usage at best 1000 times per second (once per kernel tick, like set with the CONFIG_HZ option). If the server has 1000 fps it switches 1000 times per second between the sleeping and the running state. So how should the kernel estimate the cpu usage? You can simply ignore it. Instead look at other values. The uptime command prints the "load average", i.e. the number of processes in "runnable" state at the same time (average over 1, 5 and 15 minutes). "runnable" means the process wants to have cpu time. So a "runnable" proccess it is either waiting until a cpu is free, or it is actually running. Values of the "load average" higher than your number of CPUs clearly indicate an overload. In fact for game servers it should be always considerably lower than your number of CPUs. Unfortunately I do not know a way to obtain this value for single processes...
