[ut2004] server tick rate and fps
death at apoc.org
Fri Oct 14 08:29:12 EDT 2005
Pretty sure the document on unrealadmin.org is as authoritative as it
gets... It may be old, but the recommended tickrate settings have
been pretty constant since original UT, from my experience, so I
think it's not been updated because it is still perfectly relevant to
As I understand it (I haven't read that UA.org doc in a year or more,
so take all this with a big grain of poor-memory salt), tickrate =
updates per sec... So I would think that there's a natural client-
side cap from your current net latency to/from the server (ping).
There's probably network overheads that actually slow things down
even more, but we'll go with this for now, as it still makes the case
that running tickrates higher than the default of 20 is pretty
My average ping on my cable modem is 60 ms to my own server. This
implies that I'm only getting 1/0.06s ~ 17 updates per sec,
definitely under my server's tickrate of 20, the default... From
what little I've dug around in the guts of the Unrealscipted portion
of UT's netcode (mmmm, Matrix Moves... ;) ), those updates that
never make it get dropped, and I just get a corrective nudge from the
server when updates do get through, no harm done. If my ping's down
to 50 ms one night, I'd actually be pulling all 20 updates per sec,
but better ping than that won't gain any benefit, on average. But,
crank up the tickrate to 60, and two things happen.
First, the server's got to compute and send updates to everybody 3x
as many times, and I'm pretty sure that is regardless of whether or
not the client can realistically receive them. (Is this linearly
scalable? I don't remember, but pretty sure it makes a pretty big
difference to the server, so I'll assume it is for a worst case
scenario...) So, while most decently hosted servers can handle the
elevated network bandwidth requirement, I bet my dual Athlon MP 1900+
running a round of ONS gets overloaded and laaaaags to hell, since it
already hovers at ~60% of a processor's effort at tickrate of 20.
Second, if my server were suddenly upgraded to something a bit more
badass that could handle the extra effort, the shmoe sitting on the
comp next to my server with a sweet LAN ping of 12 ms, say, would
suddenly snag a ton more updates... But what does it gain him/her?
The server is still only getting 15-25 updates per sec from other
clients, so, I guess they can have a more realistic experience
fighting the bots on the server, but that's about it.
Anyway, hope this helps.
On Oct 11, 2005, at 2:05 PM, Alex Boag-Munroe wrote:
> Oh I wasn't arguing that 60 tick is great. Its bad (tm)
> On 11/10/05, rob larkin <manifold at manifoldone.com> wrote:
>>> On 11/10/05, rob larkin <manifold at manifoldone.com> wrote:
>>>> In the last few months I've seen a lot of servers raising tick
>>>> rates to
>>>> 35 and even higher. I think it's way too high. But I'm not
>>>> having any
>>>> luck convincing anyone. And I get really annoying fps lag on
>>>> those servers especially if ppl come close to me (no p/l though,
>>>> and my
>>>> box is a good performer).
>>>> I've read all I can find (unrealadmin, etc.); I think that if the
>>>> default tick rate is 35 for lan (100mb p/s) and the default for
>>>> is 20 (56k to 3mb p/s) that should be enough info to demonstrate
>>>> that 35
>>>> is too high for internet play. But it's not. Anyone know of an
>>>> authoritative write up that's newer than that old one on unreal
>>> Alex Boag-Munroe wrote:
>>> Heh I know servers that run on 60 tick.
>>> Personally, I find 20-25 to be fine.
>>> Alex Boag-Munroe
>>> Lack of planning on your part does not constitute an emergency on
>> Yes, I also know servers that run on 60 tick. And except for a
>> of 1v1 dm servers they're horrible. Servers with high tick /can/
>> perform well most of the time, but they usually experience a big
>> at the most inconvenient time, like when there's 4 or 5 players
>> over a powerup.
>> Anyway, I'm still looking for something recent and authoritative...
> Alex Boag-Munroe
> Lack of planning on your part does not constitute an emergency on
More information about the ut2004