The relevance of FPS for srcds

[Monk]

(02-13-2011, 06:29 PM)Goilio Wrote:  This is turning into a flame war please keep it civilised. Monk please don't put more fuel on the fire, that goes for everyone. As I have stated many times before everyone has their own opinions lets just accept that and move on.

BehaartesEtwas is just giving facts that support his opinion in a civilized manor. I would definitely read a write up if you did one Monk. As always their is two sides to a story. The only way to settle this would be to get a Valve Employee here(Reading this thread as just asking a question can give you the answer you want if you ask it right).

Also I just realised how many cliché phrases and metaphors I just used

I'm working on one. It does take a bit of time to watch the same crap in gdb/ida over and over.

[BehaartesEtwas]

There is actually one effect making FPS probably more important than I said in the last couple of days (and posted on fpsmeter.org): If FPS and the tickrate are not synchronized, there can be some kind of an "aliasing" effect. Let me make this clear with an example: If the tickrate is 66 (actually 66 2/3), between each tick 15ms shall pass. Now imagine the FPS would be 68, which means between each frame only 14.7ms pass. The engine can only do a tick during a frame. If it would do every frame a new tick, the tickrate would be too high (68 instead of 66 2/3). Therefore it will limit the tickrate by not doing ticks every 68th frame or so (numbers might be slightly incorrect, but that doesn't matter here). So, between 67 ticks there would be a time of 14.7ms, but between the 67th and the next tick there would be a time of 2 times 14.7ms = 29.4ms, as one frame will be omitted. So the tickrate is unsteady! Only in the average the tickrate is really 66 2/3!

That can be actually bad, as a gap of almost 30ms might not be catched by the interpolation (esp. if the lerp value is small). In that case the client will run out of data once per second and has to extrapolate. That is bad, as it is not accurate!

If you have higher FPS, this will make this effect smaller. At 1000 fps those additional 14.7ms are reduced to only 1ms. That 1ms really does not matter, as it can be easily catched by interpolation.

So there are only a few FPS values that allow running with synchronized FPS and tickrate. Those values are for tick 66: 66 2/3 fps, 200 fps, 333 1/3 fps and 1000 fps. Especially 100 fps will be worse than 66 fps for a tick 66 server! The values for tick 100 are: 100 fps, 200 fps, 500 fps and 1000 fps.

If you want to make a good server, make sure it runs as close as possible to one of those values. If you can't match them exactly, try to get it a little lower, but never a little higher! Especially running at 66 fps slightly lower fps (like 66fps instead of those 66 2/3 fps) will only reduce the tickrate in the same way, but that doesn't matter at all, if the difference is only small. On the other hand, the moment the fps will be the tiniest bit higher than the tickrate, this aliasing effect will occur!

If you cannot reach close enough on of those values, pick one of the larger values and stay as close as possible to them. 200 fps are already enough to reduce the aliasing effect to 5ms, which is already way below the lerp value and therefore will be catched completely by the interpolation. Higher FPS will help in no way.

[molli]

How you set fps 66 2/3
fps_max 66,6? ^^

[Monk]

This sound similar to people who run sv_fps of 30 or 40 on Call of Duty. The internal heartbeat of the engine on a sv_fps of 20 is 50ms (1000 / sv_fps (built-in-lag)). So when users think raising it makes it better, the built in lag reduces to 33.3ms etc. So this causes interp/exterp to get a little out of sync because most of the time they are hard coded for sv_fps of 20. Even some animation that need 20hz serverside break, timers go off sooner than later, etc.

[BehaartesEtwas]

Monk, don't mix up the engines. The internal heartbeat of srcds is not fixed to 20.

@molli: fps_max must be an integer afaik. But fps_max is a limit, not the target value. if you keep in mind that the engine sleeps always an integer number of 1ms between the frames (at least it tries to do so... the result also depends on the kernel etc.), you should use a slightly higher fps_max value to obtain 66 2/3 fps, e.g. fps_max 70 (fps values between 66 and 70 are not possible to reach with an integer number of milliseconds!). Usually the FPS will slightly lower than 66 2/3 automatically, as frame processing also costs time, so the actual time between two frames is 15ms + the calculation time.

Problems occur, if the calculation time or some wakeup latency gets too big, in that case you can also reach values between 66 and 70 or so. To avoid those effects I use a ld_preload-lib to make the timing as close as possible to 15ms resp. 66 2/3 fps.

[Monk]

Ugh. I didn't say "srcd runs at 20hz". I said it sounds similar.