Stablizing Server FPS

[BehaartesEtwas]

(12-03-2009, 06:09 PM)css Wrote:  @Behaartes
Change in FPS doesn't affect ping. Don't trust what the game says. Use MTR like I do. It's the fact, in-game stats isn't.

Depends on your definition of "ping". The relevant "ping" is not what e.g. MTR measures in parallel to the game traffic, but the round trip times of the actual game packets, right? That is very well affected by the FPS. Only at the beginning of a frame the server looks for arrived packets. If the server "renders" a frame only every 10 ms this will effectively add some unknown (!) time between 0 and 10 ms to the RTT. That's a fact as well, but a much more important fact than what MTR says...

MTR measures the network part of the latency, FPS say something about software part of the latency. Both are important. The software part is easier to control, while a constant network latency doesn't hurt so much (because the engine can compensate it).

[Peter_Pan123]

css: your fpsmeter seems too good ^^ i tried the same kernel with your config (also 64bit), but i got not the same result. i got some drops...dont know why. you said you dont use any kind of cheats like chrt or taskeset or nice prio and iam a little bit scared about your result

[css]

(12-03-2009, 06:22 PM)BehaartesEtwas Wrote:  Only at the beginning of a frame the server looks for arrived packets. If the server "renders" a frame only every 10 ms this will effectively add some unknown (!) time between 0 and 10 ms to the RTT. That's a fact as well, but a much more important fact than what MTR says...

We're talking about 1000 FPS server which has occasional drops. It's definitely not "every 10 ms" that it generates output. It's more like 1 ms. That's why I'm saying that ping fluctuating is much more important. Ping changes from 38.6 ms -> 40.1 ms (see my post with ping statistics) means 1.5 ms of NOTHING. NO REG, NO MOVE, NO NOTHING. Even if the server calculates 100000 FPS there won't be ANY input. Server does extrapolation => bad reg. Sucks, doesn't it? You can't fix it with FPS. That's why I recommend MTR and only LAN games.

---

(12-03-2009, 06:44 PM)Peter_Pan123 Wrote:  css: your fpsmeter seems too good ^^ i tried the same kernel with your config (also 64bit), but i got not the same result. i got some drops...dont know why. you said you dont use any kind of cheats like chrt or taskeset or nice prio and iam a little bit scared about your result

If you got only few drops, then try again few times. I got the result with the premium system. I got lucky and I didn't have to do multiple runs. It's much easier with the premium because it only takes 5 minutes to do the runs.

For example Ronny had to do few runs before he got perfect: http://forums.srcds.com/viewpost/79960#pid79960

[BehaartesEtwas]

(12-03-2009, 07:41 PM)css Wrote:  We're talking about 1000 FPS server which has occasional drops. It's definitely not "every 10 ms" that it generates output. It's more like 1 ms. That's why I'm saying that ping fluctuating is much more important. Ping changes from 38.6 ms -> 40.1 ms (see my post with ping statistics) means 1.5 ms of NOTHING. NO REG, NO MOVE, NO NOTHING. Even if the server calculates 100000 FPS there won't be ANY input. Server does extrapolation => bad reg. Sucks, doesn't it? You can't fix it with FPS. That's why I recommend MTR and only LAN games.

as I said, this is correct. BUT: the other way round is also correct. meaning, if your FPS are not stable, your network latency can be as stable as it wants, you will have a bad "reg".

and another note: you again think too much in averages ;-) it doesn't matter, if the server runs most of the time with 1000 fps. what matters is, if the moment my client sends the command to hit the enemy in the head *both* the network latency and the fps are stable.

if you have only occasional fps drops (or network latency instabilities) this reduces the probability that the player sees that effect. so the question is if one can accept e.g. 1% of the hits not correctly recognized (which would correspond to 1% of fps drops in first approximation - "fps drops" are now used in a different way as in the fps meter!).

(12-03-2009, 06:44 PM)Peter_Pan123 Wrote:  css: your fpsmeter seems too good ^^ i tried the same kernel with your config (also 64bit), but i got not the same result. i got some drops...dont know why. you said you dont use any kind of cheats like chrt or taskeset or nice prio and iam a little bit scared about your result

css Wrote:If you got only few drops, then try again few times. I got the result with the premium system. I got lucky and I didn't have to do multiple runs. It's much easier with the premium because it only takes 5 minutes to do the runs.

his long time measurement doesn't look so nice
http://www.fpsmeter.org/p,view;28705;month;;beta.html

it's really not the purpose of the fps meter to run it so often until you reach your desired result. that's somewhat lying to yourself...

[css]

(12-04-2009, 02:27 AM)BehaartesEtwas Wrote:  it doesn't matter, if the server runs most of the time with 1000 fps. what matters is, if the moment my client sends the command to hit the enemy in the head *both* the network latency and the fps are stable.

If you would only take a moment and use MTR to measure ping. Even normal ping tool is sufficient, but MTR is better. Look at the variation. Ping changes all the time. It fluctuates more than it stays stable. There is significantly more fluctuation in ping than in FPS. That's why ping and ping optimization (http://www.bitwizard.nl/mtr/) overweights FPS optimization by far. Actually many server admins probably blame FPS because they have non-optimized ping. The only tool server admins have is "stats" and there the FPS is the easiest number to comprehend. If they only knew...

(12-04-2009, 02:27 AM)BehaartesEtwas Wrote:  it's really not the purpose of the fps meter to run it so often until you reach your desired result. that's somewhat lying to yourself...

Umm.. What?!

Are you saying the measurement isn't true? I Promise it's pure 100% made by fpsmeter.org measurement tool. If it's lying then I don't know what is the truth.

[Hi I am John Smith]

I am following BehaartesEtwas's guide on optimizing the Linux kernel and I got stuck.

1)
I am using CentOS 5.4 (i386), and for the packages, I don't have the following:

chrt
// I am using default repo and RPMforge, can't find chrt, schedutils, or schedtool.

zlib1g-dev
// The guide says this is for Debian 5.0/lenny. So for CentOS, no equivalent is needed at all?


2)
The "Configuring and building the Kernel" step, for:

Real Time Clock
PC-style 'CMOS'

Should they be <*> or <M>?


3)
The "Configuring and building the Kernel" step again, for building the kernel:

make && make install modules_install

make rpm && rpm -i /usr/src/redhat/RPMS/`uname -i`/kernel-2.6.26.8rt16-1.`uname -i`.rpm

For CentOS, I should use the second command?
(just want to be sure. I am already running the first one though... )

I am using:

linux-2.6.31.6.tar.gz
patch-2.6.31.6-rt19.gz

So it should be?

make rpm && rpm -i /usr/src/redhat/RPMS/i386/kernel-2.6.31.6-rt19.i386.rpm


Thank you all.

---

By the way, both my home box and my dedicated box, with the default CentOS v5.4 installation, are getting this:



- Q6600
- Currently running one instance of TF2
- Kernel is vanilla 2.6.18-164.6.1.el5
- fps_max 300

[BehaartesEtwas]

1) i386 is not what is written in the howto. I strongly recommend x86_64 / amd64 (or whatever you want to call the 64 bit platform). I don't know CentOS, so I can't tell you how to install those tools. But also I recommend against CentOS, people seem to have more problems with that distro. (if the kernel build is successful, zlib is already installed correctly).

2) doesn't matter

3) only one of those commands is required. the "CentOS version" of that command wasn't included by me in the howto. To my knowledge there is no need for any differences between distributions, unless for the part that creates the init ramdisk (which can be completely avoided by building the harddisk drivers and file systems with a [*] instead of a [M]). So make && make install modules install (or make bzImage install modules install) should be fine on *all* linuxes. no RPM stuff etc. required.


---
regarding your home pc:
what do you expect with fps_max 300? it will limit the fps to 250. maybe those jumps to below 200 can be eliminated with an "idler" process... but try fps_max 0 first!

[silent]

I am running into an issue since i changed the servers kernel. The system seems to get locked up and does not respond at all. This has occurred twice and i was told there was no error output on the systems screen at the hosting company. I can post any logs if you want but i didn't see anything in them.

[Hi I am John Smith]

BehaartesEtwas,

1)
I am going to try x86_64 then.

For my home box, I used to have Ubuntu server installed, but after the initial release of the Scout update, my box was getting some random crashes.

I guess each update would affect a certain distro, so there isn't a crash-proof distro for SRCDS. The reason that I am sticking with CentOS, is because most GSPs are using it as a default Linux OS, and thus has a larger number of users. So if any issues occured, Valve would probably apply the fixes based on CentOS. Just a guess.

3)
I tried the 2nd one, got Kernel panic. I will try the 1st one (and some other ways) and report back here later.

4)
As for the current performance for my home & dedicated box, with fps_max 300, I am trying to fine tune the boxes, to get a stable ~256, especially when with a vanilla setup (no plugin), and no player. By the way, both my boxes are mainly running SRCDS TF2 and nothing else.

I have been using shared box game server from a couple different hostings, and ~256 was what I used to be getting.

I will try the idler and the fps_max 0. Will report back a bit later.

Thanks for your help.
----------------------------------

silent,

Are those random lockups during the session, or during the bootup? I don't know, maybe you are getting Kernel panic as I am?

[silent]

The lockups happen after the system has been running. The first time it took a day the second time 2 days.

[BehaartesEtwas]

@silent: that's a differen topic and does not belong into this thread here, I guess... please open a new thread.

@TO: I don't think valve cares about distributions. But if they do they most likely will not support a community distribution but a commercial one, like debian, redhat & co. In any case if they don't do anything really strange there are no distribution-dependant issues.

Regarding the kernel panic: make sure all drivers required for boot (disk controller, file system) are build into the kernel: [*] instead of [M]. use the "lspci" command to list the devices in your box, if you don't know what dist controller you have (the name of the file system is written in the file /etc/fstab).

[silent]

@ BehaartesEtwas lol you realize i started this thread.... and from the advice on this thread ran into an issue which caused random lockups.

[Terrorkarotte]

(11-30-2009, 09:40 PM)silent Wrote:  

Code:

screen -A -m -d -S gungameserver taskset -c 0 ./srcds_run -console -game cstrike -tickrate 100 +maxplayers 23 +map fy_xbox +ip <ip> -port <port> -pingboost 3 +exec server.cfg -autoupdate

The server is also running a handful of mods:
SourceMod
MetaMod
EventScripts
Es_tools
Psychostats
GunGame
Steam Bans
and a few others.

ok lets start:
-pingboost 3 -console Does not work with linux so do not use them.
Try not to use taskset for starters. On some systems you get worse performance than without it.

23 slots seems a bit to much for me for your CPU. If you look on your first graph you will notice it becomes much more stable if the playercount is below 14. ->Try running the Server with 14 or even 12 slots and watch the cpu usage with top or htop. But be aware that these programs do not show the load peaks very good. All you see is the average cpu usage.
The srcds server has peak usage so make sure your server has no more than 80% usage of one core when all slots are filled.

Some Mods also affakts the stability. Disable all of them an look, if the server runs stable. If it does aktivate them one by one. and look for the stability.

[BehaartesEtwas]

(12-05-2009, 06:51 PM)silent Wrote:  @ BehaartesEtwas lol you realize i started this thread.... and from the advice on this thread ran into an issue which caused random lockups.

oops... sorry! must have mixed up things... I read too many topics I guess :-)

"-pingboost 3" does not work with srcds, it's simply ignored (also on windows).

23 (actually 22 usable I guess) slots are not too much for your cpu. I don't really know how your CPU compares to the Intel CPUs, but I guess it's something close to the Pentium D? Then I wouldn't run more then 1 Server per core, but 22/23 slots per core should be fine.

In any case that's currently not your major problem I guess...

can you explain your current situation a little more precise? what optimizations exactly are you using now (kernel etc.)? Do you see any abnormal log messages (in /var/log/messages) right before the crash? Can you actually see what is printed on the monitor when the server crashes (might be difficult on rented servers, I know)?

[silent]

(12-06-2009, 08:19 PM)BehaartesEtwas Wrote:  

(12-05-2009, 06:51 PM)silent Wrote:  @ BehaartesEtwas lol you realize i started this thread.... and from the advice on this thread ran into an issue which caused random lockups.

oops... sorry! must have mixed up things... I read too many topics I guess :-)

"-pingboost 3" does not work with srcds, it's simply ignored (also on windows).

23 (actually 22 usable I guess) slots are not too much for your cpu. I don't really know how your CPU compares to the Intel CPUs, but I guess it's something close to the Pentium D? Then I wouldn't run more then 1 Server per core, but 22/23 slots per core should be fine.

In any case that's currently not your major problem I guess...

can you explain your current situation a little more precise? what optimizations exactly are you using now (kernel etc.)? Do you see any abnormal log messages (in /var/log/messages) right before the crash? Can you actually see what is printed on the monitor when the server crashes (might be difficult on rented servers, I know)?

I removed pingboost 3 and yes the server is 22 slots with 1 reserve slot that is never full. We are also only running 1 server per core.

The optimization i am using is the one that was located on your wiki page. I downloaded the kernel 2.6.31.6-rt19 and configured it according to the page. I have checked the log file you stated and it has nothing inside of it around the time of the crash. As for errors on the screen the dedicated company informed me there was none. I can check other logs if you would like.