Server FPS

[stickz]

when i asked for help about server fps in my control panel, (after some questioning) i was told the following.

TimeX: "It is a difference in calculations and simulations. Entire articles have been writen on the subject, but are you seeing any specific problems? If everything seems to run fine, then I wouldn't worry about the specifics of server side numbers."

and i was also told this

TimeX: Running at a higher FPS will increase CPU usage some, yes.

i was wondering if an article could be sited about this. when looking online i stumbled apon very vague articles that never cut to the point and tell you exactly which you need 500 or 1000fps as appose to like 60 fps for instance. (or maybe 70-80fps)

i was looking for an article that said something more than "higher or better" or yah it has better "hit registration". i just couldn't find so no article.

just to be clear, i'm talking about SERVER FPS. i'm not talking about client fps. those are 2 completely different things and shouldn't be confused.

[Madhavok]

What game are you talking about?

HL1 games are able to run at 1000FPS, but Source games have a hard cap (I believe it is 100FPS)

[kraze]

Server side FPS has always been highly misunderstood and it's not common to find someone or an article written by someone who actually knows what it does.

How FPS works is going to depends on your game. I imagine since you're talking about 500 and 1000FPS you're referring to a HL1 game.

You should check out this guide.
http://www.nfoservers.com/forums/viewto ... =16&t=2028

It is very in-depth and has several interpretations on FPS, rates and tickrate.

[soja]

I read through all of this a while ago, pretty informative: https://developer.valvesoftware.com/wik ... Networking

My general rule when running a server that supports high fps: tickrate is more important. if you can run 100 tick but only 500fps, that is better than 66 tick 1000fps.

[stickz]

anther vague article that just says "lower latency". its all just trying to be as vague as possible, and not saying more than you actually know or are confident about saying.

most of the paragraph was spent talking about "network fps". i looked it up, there's no such thing.

[Edge100x]

We really do need to know what game you're talking about. FPS means different things in different games.

[Gallomimia]

The game he is talking about is "Nuclear Dawn" but there's plenty of interest in similar definitions for other games, both of the source engine and whatever else might be available. I'm personally interested in CSGO, L4D2, TF2, and somewhat interested in Killing Floor, tho it's different engine has tossed me some monkey wrenches.

[Madhavok]

I can tell you from expierence that in CS:GO that the FPS stays as same as the tickrate. 66 tickrate = 66 FPS. GO also has a cap of 128 tickrate, which to be honest is only good in smaller servers. Just because the FPS is higher doesn't mean the gameplay will be smoother with big games. A lot of people have issues with 128 tickrate on large servers.

[kraze]

Nuclear Dawn runs off the old Source Engine, and it doesn't appear it converted over to Orange Box when everything else did.

The post here explains how FPS works and what it did previously;http://www.nfoservers.com/forums/viewto ... 831#p27439

In your case that's still accurate, but it doesn't apply to different games like CS:S, TF2..etc.

i was wondering if an article could be sited about this. when looking online i stumbled apon very vague articles that never cut to the point and tell you exactly which you need 500 or 1000fps as appose to like 60 fps for instance. (or maybe 70-80fps)

There isn't a specific setting and higher isn't always better. FPS/tickrate and server rates can go very in-depth and become very confusing. Everyone also has their own interpretation of how it works.

To cut the chase and really simplify it. FPS will check if it time to run a tick. The higher the FPS the more times that check is going to occur. This also means a more accurate tick. This can result in smoother gameplay..etc.

However, as technology has advanced this has pretty become obsolete and isn't needed anymore. The internal timers are accurate enough and increasing the FPS is going to provide very little benefit, while the usage increase(CPU) is going to go way up.

[Gallomimia]

I've noticed a big issue with bandwidth when I'm on a terrible network, and server settings are often ramped up a little to deal with issues that most people see when they aren't high enough, for the bigger games like ND, which has more entities which are more active, bigger maps, and up to 32 players. Is tickrate related? How does it match up to the cmdrate, updaterate, and plain old rate?

[soja]

Bandwidth and tickrate do have a relationship. The more ticks per second the more updates the client can receive. For example 66 tick has the potential to send you 66 updates per second, and you can send the server up to 66.

Valve, for some reason, limits this by default to I think 20 down and 30 up? I haven't used valves default rates in so long. This ends up in less work for the server, but means less accurate player movement.

Those values are conrolled on the server by:
sv_minupdaterate - Sets the minimum updates the client can receive
sv_maxupdaterate - Sets the maximum updates the client can receive

sv_mincmdrate - Sets the minimum amount of updates the client can send
sv_maxcmdrate - Sets the maximum amount of updates the client can send

Client side:
cl_updaterate - Sets how many updates you want to receive from the server
cl_cmdrate - Sets how many updates you want to send to the server


On my servers, I believe sending and receiving the most updates gives the most accurate play experience, so I restrict clients to a MINIMUM of 46 updates on 66 tick servers. Meaning if they set their cl_ whatever to less, the server still forces 46 updates. On our BHOP server(100-tick CS:S) we force clients to run all 100 updates, to avoid noobs saying our server doesn't function properly.

rate - This, on the client side, sets how much information you are willing to receive from the server in Bytes/s.

Server variables:
sv_minrate - Sets the minimum value the client may have for rate
sv_maxrate - Sets the maximum value the client may have for rate(usually 0 for unlimited)

NFO enforces a sv_minrate of 100000(100KB/s), which is a great value. This means clients do not get choke even when a lot of action is going on, which players can interpret as lag or poor server performance.



Out of order a little, big maps:
Large maps that are made well have something(I can't remember what it is called) that breaks up the information, so for example something a player is doing in the other corner of the map, you wouldn't know about. This is important because compressing data sent to clients takes a lot of CPU power when you are sending lots of info(in a large server for example). Poorly made maps do not have these implemented, resulting in higher CPU usage and more bandwidth used.



EDIT: Wow wall of text lol