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
TDM-Pro, 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 UT.
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, UT
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 UT 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 UT 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 >>
