This is part 5 in a series.

The source engine netcode is a little squirrelly. It always has been and it always  will be. One of the questions I am bombarded with is ‘How do I fix XYZ to make the game run better?’ In order to make the universe a slightly better place, I’m going to try and help all of you.

Articles in this series will include:

1. The basics of how source netcode works
2. How the source engine compensates for an imperfect environment
3. Understanding the Netgraph
4. Optimization Guide
5. Everything else advanced and so far not covered (You are Here)

What’s left?

There are mountains of things left, in all honesty. Source is not a simple or shallow topic. Most of the topics left are either worthless or impossible to understand without access to the source of the source engine.

The two remaining topics of the most instrumental value are cl_interp_ratio and Server FPS.

One is relatively useable and the other is good information, considering there are huge misconceptions running around about it.

cl_interp_ratio

A long time ago, the dilapidated cl_interp command was replaced with cl_interp_ratio. This change was welcome, considering cl_interp was defaulted for cl_updaterate 20. No one was using cl_updaterate 20 anymore and the information on how to set cl_interp to make interpolation useful was not readily available. Accordingly, we got cl_interp_ratio.

For anyone who wants to know that old equation, it was

cl_interp = 2 / cl_updaterate

cl_interp_ratio does the work of setting interp based off of your cl_updaterate for  you. It works pretty well. You can optimize it if you are on a server which will allow you to, but most of the times cl_interp_ratio is forced to 1.

Regardless of the server you are on, here’s the important part:

If you adjust your cl_updaterate, your interp will also be adjusted. End of story.

The new equation is

cl_interp_ratio/cl_updaterate = Interpolation

Here are some tables from Whisper’’s Wiki to help anyone who wants to optimize their ratio.

cl_interp_ratio 1.0	cl_updaterate 30	interpolation = 0.033
cl_interp_ratio 1.0	cl_updaterate 35	interpolation = 0.029
cl_interp_ratio 1.0	cl_updaterate 40	interpolation = 0.025
cl_interp_ratio 1.0	cl_updaterate 50	interpolation = 0.020
cl_interp_ratio 1.0	cl_updaterate 60	iinterpolation = 0.017
cl_interp_ratio 1.0	cl_updaterate 66	interpolation = 0.015
cl_interp_ratio 1.0	cl_updaterate 75	interpolation = 0.013
cl_interp_ratio 1.0	cl_updaterate 80	interpolation = 0.013
cl_interp_ratio 1.0	cl_updaterate 100	interpolation = 0.010

For anyone who is running  cl_interp_ratio != 1 Whisper’s Wiki has some other great tables to help you.

Server FPS

Oh dear. This topic is one of the least understood and most debated topics in the source community. The problem coming from the fact that no one really knows how this all works, they all just make the best educated guess they can based off documentation and inference.

I’ll lay it down flat with as much legitimate proof as I can muster.

The Explanation

Returning to the basic netcode: Everything that happens in a CS:S server is calculated by frames. These frames are the snapshots that we discussed earlier. The more frames a server can calculate per second, the more accurate the data will be.

This is where the ‘1000fps is best’ mentality comes from. If you look at it just from this perspective, it makes sense.  At 1000fps the server will calculate the world at 1 frame/millisecond. Compare that to 100fps which is 1 frame/10 milliseconds. (Credit: Meat Factory)

Much higher, right? Yes, but the client runs at a much slower rate due to the limit of server tickrate.

Unlike other games where server FPS directly translates to tickrate, Source has a tickrate independent of server FPS. As mentioned earlier in the series, the tickrate defines the maximum amount of updates per second a client can receive. This is where the client/tickrate come into play vs server fps.

The server may be able to calculate the world every millisecond, but the client is only sending/receiving updates every 10 milliseconds. Meaning, the server is making calculations based off old client data 9/10 times at 1000fps.

To summarize what we have to far: 1000fps servers can calculate their world at a much faster rate than 100fps servers, but clients only send data at the rate of the 100fps server. Meaning the extra calculations on the 1000fps server are based off of the same amount of data as the 100fps server.

I asked Laws from HiDef about this subject and I’ll paraphrase what he had to say.

What 1000fps is doing is making more calculations than necessary on the server side, so when the data is sent to the client it is the most accurate as possible. With a 100fps server, it will make the necessary number of calculations to play the game at near optimal performance assuming fps never dips and a bunch of other variables never fluctuate. The 1000fps server gives you that TINY fraction of a percent chance that the server will make a more accurate calculation based off of the same data.

The Good

A 1000fps server will reduce the possibility for a skewed update because of how many extra calculations it does.

The Bad

We need to consider more than just the netcode here. We don’t live in a perfect world, remember? Everything up until this point is assuming that there are NO fluctuations in any variables and we have unlimited server resources.

That is not the case.

Here is where 1000fps doesn’t look so good. It runs so fast and demands so much CPU that it can easily overload a server. Whenever anything happens in game - firefights, smoke grenades, etc. - the server is taxed. At a higher FPS, this may be too much for the server to handle and the outcome is never good.

Once overloaded, the server FPS may dive. The game server is unstable. That minute chance of a more accurate calculation is gone because the fps dropped.

The game server may also screw up the scheduling of the CPU causing all sorts of good lag spikes, etc.

End of story - 1000fps is not as stable as lower fps.

The Ugly

Now you have the readers digest version of server fps. It is time to weigh in the pros and cons.

Higher FPS (600+)

Pros:

• More calculations per second - you are less likely to end up with a skewed update. Updates will the ‘most’ accurate as possible.

Cons:

• MUCH harder on server resources.
• May cause instability issues.
• Expensive

Medium FPS (333-500)

Pros:

• Provides adequate headroom for variable fluctuation without introducing tendency for instability. (Remember, choke will occur if the the server FPS drops lower than the rate of data demanded by updaterate or rate.)
• Provides more calculations per second than low fps.
• Stable (this also depends on the server host)

Cons:

• Not as many calculations as 1000fps
• More expensive than lower FPS.

Low FPS (300-)

Pros:

• Cheapest
• If no variables fluctuate, it provides almost the exact same performance as Medium/High FPS server.

Cons:

• Fewest number of calculations. Larger possibility for inaccurate data.
• If ANYTHING fluctuates and/or goes wrong you will dip below the 100fps. Thus, susceptible to a different type of instability.

The Verdict

Recommendations are personal opinion based off my knowledge on this subject.

What should I buy?

Public  Server: 333FPS (Preferred) or 500FPS

With all the mods and addons most public servers run, having a server higher than 333fps is likely to cause instability. Although, if you are in an adequate server environment, you can 500FPS with little to no problems.

Private Server: 500fps

Private servers tend to be less demanding on server resources than public servers. You should be able to easily get away with 500fps without causing instability issues.500fps is the best combination of price and performance from most server hosts.

Do not buy a higher fps server from a worse quality server host over a lower fps server from a higher quality server host. Good hardware which has not been overloaded will produce much better results at a lower fps than an overloaded box at higher fps.

There’s Nothing Left

Thanks for reading. If you want me to cover another topic, just let me know.