Extremely High CPU Usage

[Monk]

Looks like it's timing out, perhaps because it's pegging the CPU and it cannot answer futex requests in a timly manner. Also looks like it's being interrupted by a signal, and trying to resume, only to return EAGAIN

[BehaartesEtwas]

jimmy, what is it you want? do you want to have some nice fps number somewhere? or do you want to have an acceptable game play?
you will not reach (constant) 1000 fps wit 64 filled slots on your cpu, regardless what you try to optimize. I think now most of the people here at the forums that had a deep look into srcds agree, that fps larger than the tickrate do not improve the game play and thus waste only resources (on orangebox games - it was different before OB). so why don't you give it a try? my servers run with 66 fps for a couple of days now, and I noticed no difference. Also nobody else on the server didn't, even when I was explicitly asking. (Before you ask: yes we have some decent players there who would notice even tiny differences in the game play.)
so give it a shot, remove all stuff that is designed to give you 1000 fps (especially that adaptive sleep thingy, that costs extra cpu of course!) and set fps_max 67 (or try slightly higher values if it drops even when empty). If that is not enough to prevent lags, you will have to go even lower (thus lowering the tickrate - this is not fake btw but a really lower tickrate!). Better a "low" (33 isn't actually low, it was standard not too many years ago) rate than lags, right?

[bakak]

the server is running at 66 fps, the players have low fps, is not it?

[jimmy69]

I'm looking for acceptable gameplay, nothing more or less. There's too much external variance for players (I've removed Adaptive Usleep for now, against my better judgement). As far as setting sv_maxcmdrate to 33 along with sv_maxupdaterate that will not do much as the server is still operating at 66tick. As a result of this, the server expects 66 back, however it will not receive it.

[Monk]

You're probably reaching the limits of your CPU with 64 players, so unfortantely the game is just at it's peak. No matter what kernel stuff you use/run/change/alter/manipulate, the game is still pegged.

Older versions of srcds were less expensive, FWIW.

[jimmy69]

Ugh

I wish Valve took performance semi-seriously.

[bakak]

@BehaartesEtwas

How should we do in the kernel settings for 67 fps, your server set fps_max 0 but at 67 fps

[BehaartesEtwas]

(10-19-2010, 01:14 AM)jimmy69 Wrote:  I'm looking for acceptable gameplay, nothing more or less. There's too much external variance for players (I've removed Adaptive Usleep for now, against my better judgement).

I strongly recommend fixing any serious lag issues first before even thinking about "variations". It simply doesn't help, if your server is running smooth in theory but has big lags when filled with players.

(10-19-2010, 01:14 AM)jimmy69 Wrote:  As far as setting sv_maxcmdrate to 33 along with sv_maxupdaterate that will not do much as the server is still operating at 66tick. As a result of this, the server expects 66 back, however it will not receive it.

untrue. the tickrate is only the maximum for the two variables sv_maxcmdrate and sv_maxupdaterate. or - differently expressed - the effective tickrate is the bigger number of sv_maxcmdrate and sv_maxupdaterate, but never bigger than 66. the server does not expect anything, it uses what it gets. simply try it out and be honest with yourself (i.e. do not prejudge the ingame feeling from the settings).

(10-19-2010, 08:45 PM)bakak Wrote:  How should we do in the kernel settings for 67 fps, your server set fps_max 0 but at 67 fps

This has nothing to do with kernel settings. I still use a special LD_PRELOAD lib to have the same timing precision as before. Probably this is not really necessary, but it doesn't hurt, so I still use it.

bakak Wrote:the server is running at 66 fps, the players have low fps, is not it?

client and server fps have nothing to do with each other. clients can have 100 or more fps even if the server runs with 33 fps or so. since the OB update, server fps only limit the tickrate, i.e. limit effectively sv_maxupdaterate.

[jimmy69]

Besides more FPS jitter then normal, there is no change with enabling or disabling adaptive usleep.

[bakak]

we need something new to us for ob

[BehaartesEtwas]

(10-21-2010, 03:35 AM)bakak Wrote:  we need something new to us for ob

in fact, the OB helps a lot my itself. we don't need to do that much as before.

ok, the cpu load got higher in theory, but as we can use much lower fps, it is probably even lower in reality.

jimmy, at how many fps are you now running?

[bakak]

Well,

fps_max 67, sv_maxupdaterate & sv_maxcmdrate 67 with zen kernel results

32/34 players on server

the beginning of round 90-95 cpu usage but after 10 seconds fall 65-75 to..

50-66 fps in the situation

[BehaartesEtwas]

you are not jimmy? :-)

at the beginning of the round there is much load due to the respawning of all players. maybe also some plugins that do some checks at round start or player spawn will additionally produce load.

is there any visible lag at round start? the round start isn't so important, so if the actual game play is not affected (i.e. the fps are stable during the round apart from the beginning), you are probably fine...

but as I pointed out, the cpu usage is not something that helps judeging the server quality. look at the fps stability. they have to say above the desired tick rate. if they do, your server is fine even though it might have 99% cpu load. if it does not, your server isn't fine, even if it has 10% cpu load only. ;-)

[jimmy69]

80 -> 800 FPS, still caps out at the same point.