What exactly does fps_max control?

[Crispy]

Does anyone here have access to the srcds source code, or have inside information about fps_max? I'm trying to find out exactly what sequence of steps is being governed by the fps_max cvar.

The Source Multiplayer Networking wiki talks about "ticks", but not about "frames": "The server simulates the game in discrete time steps called ticks. By default, the timestep is 15ms, so 66.666... ticks per second are simulated, but mods can specify their own tickrate. During each tick, the server processes incoming user commands, runs a physical simulation step, checks the game rules, and updates all object states. After simulating a tick, the server decides if any client needs a world update and takes a snapshot of the current world state if necessary."

What this tells me is that the srcds simulation engine runs once every 15 ms, and at the end of the run, the state of the world is saved to memory. If at this time there are any clients that need to be updated, then the saved world state is sent to those clients. Breaking it down, that gives us the simulation engine, which is triggered (hopefully by an interrupt) once every 15 ms, and some networking code which is triggered by an event generated at the end of the simulation. Where do the server "frames" fit into this model, and what exactly does the server do every "frame"?

I could take a guess that the server code is polling a timer once every "frame", and checking to see if it's time to run the simulation engine, but that would be a really bad design (interrupts are preferable to polling for low frequency events). However if the simulation engine is triggered by an interrupt, I can see no need for code that loops 1000 times per second, or whatever fps_max is set to.

Any insight on this subject will be most welcome.

[BehaartesEtwas]

(03-27-2011, 01:00 PM)Crispy Wrote:  Does anyone here have access to the srcds source code, or have inside information about fps_max?

not really, although there is some very old leaked source code somewhere in the net of an early beta version of half-life 2. nevertheless, even without the source code one can answer your questions from observing behaviour.

your picture is almost right. a frame is some residual from the client and listen server, where actually graphical frames are rendered while acting as server simultaneously. a dedicated server does not render graphical frames, but everything else is kept identically. the situation on an orangebox dedicated server is like this:

the server sleeps 1ms, then it checks if the last rendered frame is at least that amount time ago which you defined with fps_max (i.e. the inverse of fps_max). if not, it immediately starts over with sleeping 1ms. this is the reason why usually only certain fps values are possible (only integer number of milliseconds).

during a frame the engine will determine if it's necessary to calculate a new snapshot (=tick) and send it to the clients. fortunately (or not...) the tick rate limiter works different than the frame limiter, as it checks the average tick rate (though I don't know over which time the average runs), so the average time between ticks does not have to be an integer multiply of the time between frames. this is not so fortunate as this can lead to kind of an aliasing effect resulting in big gaps between ticks (almost twice the desired time between two ticks), if your fps are only slightly above the tick rate (so make it equal or slightly less, or very much higher than the tick rate).

before the orange box engine also incoming network packets were handled only during a frame. this is no fortunately moved to a dedicated thread, which improved the game experience very much (and made the hight of the fps much less important - if you handle the aliasing effect correctly).

Quote:I could take a guess that the server code is polling a timer once every "frame", and checking to see if it's time to run the simulation engine, but that would be a really bad design (interrupts are preferable to polling for low frequency events).

you are correct, this is kind of a bad design. but I guess valve hesitates to change this, as they do not want to make client and server too different. equal behaviour is very important for the input prediction to work correctly.

[Monk]

(03-27-2011, 01:00 PM)Crispy Wrote:  Does anyone here have access to the srcds source code, or have inside information about fps_max? I'm trying to find out exactly what sequence of steps is being governed by the fps_max cvar.

The Source Multiplayer Networking wiki talks about "ticks", but not about "frames": "The server simulates the game in discrete time steps called ticks. By default, the timestep is 15ms, so 66.666... ticks per second are simulated, but mods can specify their own tickrate. During each tick, the server processes incoming user commands, runs a physical simulation step, checks the game rules, and updates all object states. After simulating a tick, the server decides if any client needs a world update and takes a snapshot of the current world state if necessary."

What this tells me is that the srcds simulation engine runs once every 15 ms, and at the end of the run, the state of the world is saved to memory. If at this time there are any clients that need to be updated, then the saved world state is sent to those clients. Breaking it down, that gives us the simulation engine, which is triggered (hopefully by an interrupt) once every 15 ms, and some networking code which is triggered by an event generated at the end of the simulation. Where do the server "frames" fit into this model, and what exactly does the server do every "frame"?

I could take a guess that the server code is polling a timer once every "frame", and checking to see if it's time to run the simulation engine, but that would be a really bad design (interrupts are preferable to polling for low frequency events). However if the simulation engine is triggered by an interrupt, I can see no need for code that loops 1000 times per second, or whatever fps_max is set to.

Any insight on this subject will be most welcome.

Nobody knows. Everyone always posts speculation. No scientific paper, nothing. Even the leaked Source code was altered a bunch and the tickrate crap wasn't included.

With that being said, VALVe code is based on Quake netcode; it operates in the same manner (functions are different obviously), but the fundamentals are still consistent.

FWIW, the valve multiplayer networking wiki thing has been altered by non valve employees. The information there is tainted, so we really don't know what happens anymore.

PS. The FPS_MAX stuff should be removed from all VALVe games, or set to FCVAR_CHEAT and lock it at the default.

You should ask on the hlds_linux mailing list.