Netspeed, FPS caps, and practical UT2004 networking explanation

[Anonymous.]

Unfortunately the networking in UT2004 was built around backwards compatibility with extremely slow connections. Now that it's 2023 and most people have stable 1Mbit+ connections, we have to work around the cruft of retarded limits which have plagued us for the entirety of the game's life. This guide is not really meant for us at Omni since Snarf's mutator already does everything for us, with zero understanding required on our part. It is meant more for servers that may still be running the default bandwidth limits, and players that still have to manually set their netspeed. On top of that, this guide will try to undo the damage done by other guides that created a Pavlovian response to make players think "netspeed = uncap FPS command," resulting in players using netspeed 10001 to get around the 90 FPS cap while shooting themselves in the foot.

Firstly, the stat net command. It can also be accessed by pressing F6. It shows numerous network statistics, but what we're interested in are the bandwidths from and to the server, and netspeed.

stat net.png (27.13 KiB) Viewed 2197 times

By default, servers are capped to 15000 bytes/sec bandwidth to send per client, but if the server has more than 16 player slots, it will instead be capped to 10000B/s. 15000B/s is not a lot of data, especially on a server with a high tick rate and many players. Heavy game types like Assault, Invasion, or Onslaught will quickly pin the bandwidth limit even with fewer players and lower tick rate. For players, the cap is usually 9636 or less. This means you can only send and receive up to 9636B/s. If the server tries to send 20000B/s (or however much) while you are capped at 9636, your client will drop information. Likewise, when you try to run high FPS, you will need to send more data to the server, where the 9636 will be quickly saturated.

The "In" bandwidth is responsible for how much data you receive from the server. If there is a lot going on, the bandwidth limit will quickly be reached and you will experience missing effects, delayed actions such as death/respawn, etc. At Omni the "In" bandwidth hovers at 15000-40000B/s depending on activity, which is >2x the standard 10000B/s limit that we had due to being a >16 slot server. That is a lot of data to drop.

The "Out" bandwidth is responsible for how much data you send to the server. Once you reach the cap, you will experience rubber-banding and dropped inputs such as "use." On higher ping servers however, even with properly configured netspeed you will still rubber band at higher FPS values (250+) unless they use a recent UTComp/3SPN build which fixes this issue. So if you intend to play on servers that are far away, you may need to cap to 200 or less FPS to prevent rubber banding and other issues.

For players:
Netspeed = Command to change your bandwidth limit in bytes to the server. The server and your client will only use the necessary amount of bandwidth; netspeed in and of itself is only a limiter. Netspeed cannot be raised above MaxClientRate, so you must also increase MaxClientRate. Once you've done this, every time the server changes maps you must type in the console (`~ key) netspeed 100000 to increase your netspeed (it resets on map switch). At Omni this is already done for you, and on many other servers that use UTComp. You can create a keybind by typing in the console: set input h netspeed 100000 - every time your press "H" you will set netspeed to 100000.

[IpDrv.TcpNetDriver]
MaxClientRate = Bandwidth limit, in bytes, of how high you can set your netspeed. Set this to 100000. (This setting is located in ut2004.ini/ut2004-win64.ini, again on Omni this is already done for you).

And now for the explanation of FPS caps. For those unfamiliar with the "netspeed" command, it is closely intertwined with the online FPS cap. The practical use of netspeed until recently was to unlock the FPS cap, which is 90 by default. By changing netspeed>10000, the MaxClientFrameRate setting is used. This exists in ut2004.ini/ut2004-win64.ini for 64 bit:

Code: Select all

[Engine.LevelInfo]
MaxClientFrameRate=90

On Windows 7 and earlier, the game will round up to the nearest factor of 1000. If you input 249, it will round up to 250 FPS. On newer Windows versions, it will instead round down. Therefore if you want 250, you would need 251. The possible FPS caps are {...,90,100,111,125,142,166,200,250,333,500,...}. In case you have not noticed, you can only set the FPS cap to factors of 1000 (this varies depending on the system timer). Take note these are rounded values, only {..., 100, 125, 200, 250, 500, ...} will cleanly go into 1000, which are the ones you should use.

If you have a high refresh rate monitor, set your monitor's refresh rate to the FPS cap to ensure there is no stutter caused by a mismatch in FPS/Hz (e.g. use 250FPS / 250Hz). Otherwise, cap your FPS to a multiple of the monitor's refresh rate (if you have a 144Hz monitor then use 125Hz and 125 or 250 FPS depending on what your system can handle). You can also use variable refresh rate if your monitor supports it, but it adds latency depending on the monitor and GPU vendor (FreeSync has historically worse latency than G-Sync, around 1ms).

The game requests a timer resolution of 1.00ms, which the cap depends on. The FPS cap will not work properly unless the timer resolution is 1.00ms. On Windows 10+, the timer interrupt source was changed which broke the cap. Therefore you will see strange values, and the cap will not be stable. You must use Windows 7 or older if you want a properly working cap without having to use an external frame limiter which adds at least 1 frame of delay.

For server admins:
Before doing anything else, use the 64-bit UCC binary for ~20%+ less overhead in CPU cycles. This is as close to free performance as you can get.
From webadmin, you can paste the commands below and they will take effect after a map switch:

Code: Select all

set Engine.GameInfo MaxPlayers 16
set IpDrv.TcpNetDriver MaxClientRate 150000
set IpDrv.TcpNetDriver MaxInternetClientRate 150000

MaxClientRate = Set this to whatever you set MaxInternetClientRate to below
MaxInternetClientRate = Bandwidth limit, in bytes, of how much data the server can send to each client. As a server admin you must increase MaxInternetClientRate so the server can send more data to clients, otherwise information will be dropped once your server hits the default 10000 limit. Set it to 100000 and forget it unless you run a high tick rate, heavily populated server, in which case you will need to go above 100000. This setting takes effect after a map switch (via set command).
NetServerMaxTickRate = Server tick rate. The higher the tick rate, the lower the interval between server game state updates, which requires more bandwidth to relay information to clients. Increase MaxInternetClientRate accordingly to ensure data doesn't get dropped. Tick rate can be adjusted on the fly; instant effect (via set command). The max tick rate is 125. The higher the tick rate, the higher the CPU usage, but any modern CPU should be able to handle 40+ even with 32 players. Higher tick rate also obviously results in lower in game ping (time between ticks decreases).

Code: Select all

set IpDrv.TcpNetDriver NetServerMaxTickRate #

And while logged in, you can check the server's current tick rate:

Code: Select all

admin getcurrenttickrate

Code: Select all

[Engine.GameInfo]
MaxPlayers=16

MaxPlayers = The maximum number of player slots your server has. This setting also overrides MaxInternetClientRate. If MaxPlayers>16, then the server will limit MaxInternetClientRate=10000, which will cause severe lag once the bandwidth limit is reached. Either set MaxPlayers=16, or use Snarf's BandwidthFix mutator which gets around the limit by increasing MaxPlayers each game. It can also set MaxClientRate and ConfiguredInternetSpeed for clients. This is ideal to ensure each player gets a consistent experience without having to do anything on their part or even know what netspeed/MaxClientRate is. MaxPlayers takes effect after a map switch (via set command).

Conclusion:
Once everything is properly configured on both the server's and clients' sides, the "In" and "Out" bandwidth in bytes shown in the image above should no longer be constrained to the default 10000 limit, which means no more bandwidth limit-related lag.

[infinitecat]

Excellent overview, Anon.

Though, for me, it's just "keep pressing buttons until I kill someone or I die".

Still fun, though.

[Anonymous.]

Thanks You may have noticed recently that your lasers no longer disappear, among other things, and it's thanks to Snarf's mutator that does all of this for us.

[YEAAAHHHHHHHHHH]

Yeah the phoenix lasers look insane now!

[trans_lux]

Thanks You may have noticed recently that your lasers no longer disappear, among other things, and it's thanks to Snarf's mutator that does all of this for us.

What would your recommended settings be for a 2560 x1440 @ 170Hz?
If it matters I usually have a fairly low ping.

[captainsnarf]

You are already set at 100000 which is the server max.

[pooty]

What would your recommended settings be for a 2560 x1440 @ 170Hz?

So you really want to get that 170 fps or better... which you mostly should get with a decent card. If you don't get that high framerate, try lowering the texture detail a step or two.

[captainsnarf]

Turn off 'reduce mouse lag'. I get like 5x fps with that turned off.

In UT2004.ini, under [Engine.LevelInfo], set MaxClientFrameRate=252

[Enyo]

Turn off 'reduce mouse lag'. I get like 5x fps with that turned off.

In UT2004.ini, under [Engine.LevelInfo], set MaxClientFrameRate=252

Why 252 instead of 251? Doesn’t it round down to 250 regardless?

[captainsnarf]

Yes it rounds down. 252 for margin of error Anything between 251 and 332 will be the same 250fps.