Sniper's Paradise!
[Players Guide to Unreal Netcode]
5. Server Configuration
This section is meant for server admins; I will try to explain the main options that are configurable on Unreal servers. For nearly everything, having an admin password is enough to change settings - use "admin set ipdrv.tcpnetdriver <variable> <value>" after doing an adminlogin. To get the current values, use "get" instead of "set" (and remove the <value> part).
As mentioned above, the relevant settings for Unreal netcode on servers are found under the ipdrv.tcpnetdriver section of unrealtournament.ini (or in whatever ini your server uses). It looks like this:
[IpDrv.TcpNetDriver]
| AllowDownloads=True | allows clients to download missing packages like maps or mods from the server |
| ConnectionTimeout=15.0 | this is the time the server waits after getting no more traffic from a client before it decides "client disconnected" |
| InitialConnectTimeout=150.0 | this is basically the same as above, but applies while client is not already in game (e.g. while client tries to connect). if your server is experiencing the "creeping ping" bug, set this to something like 15 to lower the duration of the bug |
| AckTimeout=1.0 | does nothing at all in current versions |
| KeepAliveTime=0.2 | the time after which a server sends a packet regardless of actual updates neccessary. see below. |
| MaxClientRate=20000 | maximum bandwidth the server allows for server->client traffic; for each client, minimum of clients netspeed and maxclientrate is used. this does NOT apply to client->server traffic. |
| SimLatency=0 | does nothing at all in current versions |
| RelevantTimeout=5.0 | leave at default - see chapter 6 |
| SpawnPrioritySeconds=1.0 | leave at default |
| ServerTravelPause=4.0 | time the server waits after map end before switching to next map |
| NetServerMaxTickRate=20 | server "fps" used for internet servers |
| LanServerMaxTickRate=35 | server "fps" used for servers started with
?lanplay url |
| DownloadManagers=
IpDrv.HTTPDownload |
dont change |
| DownloadManagers=
Engine.ChannelDownload |
dont change |
Most of the values above don't have to be changed and won't make a big difference in most cases. The major exceptions from this are InitialConnectTimeout (lower this to 15 if your clients experience "creeping ping" bug) and of course the much discussed NetServerMaxTickrate, usually refered to simply as tickrate.
When deciding what tickrate to use on your server, there are several things to consider:
- Server OS: While Windows-based servers actually behave like they
should, Linux servers do not. More on this later.
- Client connections: For ffa servers, you may (or may not) want
to keep your server playable for modem players with very limited
bandwidth; for clan servers, your clients usually will have ISDN
or better connections. Also consider if many international matches
are played on the server - long international routes might have
low bandwidth even for clients that have a high local bandwidth.
- Maximum players and gametype/mod: Obviously, the more players
on the server the more bandwidth each client will need (more players
visible, more other stuff like projectiles to send to the clients).
The gametype/mod also is important since e.g. CTF will usually
produce a lot more spam and players visible at the same time than
TeamDM, while total conversions like TO, SF and all the others
might produce totally different traffic. A well known example
might be the "extreme" mod that generates FAR more traffic
than normal Unreal.
So what is it that makes Linux servers different from Windows servers? The results are known to most: the number of packets sent per second is not constantly at netservermaxtickrate. By design, Unreal should send a packet every tick (see chapter 6), but even when being far below 50% cpu usage, Linux servers tend to send less and not even a constant number of packets. This also affects f6 ping - if a client recieves only 10 packets/second, it might have to wait 100 ms until his ping request is acknowledged!
One (possibly the only) reason for this is a problem in Linux Unreal threading. Threading is the concept that allows for multitasking: programms tell the OS they are done with their current task for now and hand over cpu time back to it. It seems that the commands doing this in Linux Unreal are not written correct, so the server "sleeps" (between executing ticks) for a longer time than it should. This means the server actually runs at a lower tickrate than the configured netservermaxtickrate even if there is plenty cpu time left. The rate at which this happens varies with time and possibly with other unknown factors.
Unfortunately, there is no real cure known for this so far. In most cases it seems that servers tend to send packets at a nearly constant tickrate at least when there is enough "action" in game, but even this is not always the case.
With all this to consider, it is not easy to find the "perfect" tickrate for a server. Before we get to recommendations for some cases, another note on how tickrate relates to traffic. While it is generally true that a higher tickrate causes more traffic, the increase is not linear (2x tickrate does not mean 2x traffic). The reason for that is simple - while some stuff (such as player aim) actually changes often enough to result in updates ready to be sent each tick, other things do not (e.g. players do not shoot more often, players dont change movement direction more often). And when there is nothing to update on a specific thing (new projectile, new movement direction,..), no traffic is generated for that. As a result, increasing tickrate by factor x will create less than x times the traffic.
With all this in mind, some recommendations for tickrate settings in various cases will follow. These are meant for Windows servers; since Linux servers never run faster than they should, these can be used for Linux servers, too. The values assume a bandwidth of at least 5000 bytes/second full duplex for players connection unless mentioned otherwise.
1on1 servers: This is easy. With only two players generating "action", there is no real bandwidth problem; you should be fine with running at tickrate 50.
4on4 tdm servers: Tickrates around 40 have proven to be reasonable. If only players with at least 6500 bytes/sec bandwidth connect (like in an average german clan match), tickrate 50 seems to make best use of the bandwidth.
5on5 ctf servers: Tickrate 30-35 should be fine.
For international matches, you will have to consider if there really is a bandwitdh of 5kb/sec available between clients and the server. If clients start getting packet loss or ping increases that do not appear with lower tickrates, there most probably is some bottleneck in between.
In case you wonder why Epic themselves recommend much lower values - there are two simple reasons for that: First they have to consider the average buyer who might have a 56k modem (and analog modems dont get close to full duplex), so they assume netspeeds like 2800 - and servers with 16 players. This does not seem reasonable today and especially not for the average regular online player. The second reason is that epic never cared for competative gaming, so as long as the game is actually playable in some way (in the meaning of the word, not what a regular online gamer would call playable), it's fine from their perspective.
<< 4. Advanced stats 6. Advanced netcode >>
All logos and trademarks are properties of their respective owners.
Unreal™ is a registered trademark of Epic Games Inc.
Privacy Policy
Website by Softly
Powered by RUSH