SRCDS Steam group

'0.0 unusable' after kernel optimization
Server OS: Fedora 12 32-bit (running kernel
Processor: Intel Xeon E5430 (X3353), 4 x 2.66GHz, 12MB L2 Cache, 1333MHz FSB
Ram: 4 GB
Game(s): TF2
Start Up Command: ./srcds_run -game tf -timeout 30 -console +ip -port 27028 +maxplayers 32 +fps_max 600 +exec server6.cfg +map ctf_doublecross -secure +mapcyclefile mapcycle6.txt
Admin Mods: Metamod, Sourcemod

Having applied the realtime kernel optimizations, I am still getting absolutely terrible server fps:

[Image: graph.php?id=70279]

I've tried running both 1 and 4 instances of the idler program, and fiddling with other sirq process priorities, but the fps is still awful. Any ideas? :S
Yea. I do not have that extrem. But since the last big update that broke all addons the server binarys have changed. The new versions tend to be very unstable regarding to server fps when you reach high slot counts. Before the update i had no troubles with dods and 32/32 slots @ tick 100. After the update even a 28/32 @ tick 66 becomes unstabel like you see it in your graph. The slot and server amount on that system did not change. The only thing was the update.

So either the birays are really buggy or metamod/sourcemod. I had no chnace in testing cause I need that addons.

If you can run a test without them.
Turned off cpu scaling in the bios?
I only have SSH access - is there any way I can do/check that without getting my host to fire up KVM?

Edit: Just realised I had the cpuspeed daemon running, but not much of an improvement with it off.

Edit 2: Turns out I also have the acpi_cpufreq module running, but it refuses to be unloaded >.>

[root@gamingmasters ~]# rmmod acpi_cpufreq
ERROR: Module acpi_cpufreq is in use
[root@gamingmasters ~]# rmmod -f acpi_cpufreq
ERROR: Removing 'acpi_cpufreq': Resource temporarily unavailable

Edit 3: Blacklisted it and it's gone after a reboot - will post results shortly...

Edit 4: Nope, still bad fps.
the server is tick 66, right? try running with 66 fps, just for a test: use fps_max 70
then do another test with fps_max 0
and post both measurements here...

it might just be that the single core performace of your cpu is too low to handle so many players...

so try with less players (i.e. make a measurement during a time when fewer players are on the server). maybe you'll find a "threshold" of the player count when it starts fps dropping. and if you are lucky you can find ways to shift this threshold, e.g. by decreasing the fps and tickrate.

you also might try different kernel optimizations. RT patches optimize for low latency at a trade-off of a higher cpu usage. So you might want to try the opposite: use a vanilla kernel (= unpatched) with HZ=100, no preemption but with dynamic ticks enabled. at least that could be a point to start... (Linux Kernel HOWTO!)
Do not ask technical questions via PM!
It's still pretty bad with fps_max 70 :<

I'll try a 100hz vanilla kernel later when the servers die down a bit Smile

Forum Jump:

Users browsing this thread: 1 Guest(s)