Tickrates, Framerates and other such mysteries! Options

[MonkeyFiend]

Tickrates, Framerates and other such mysteries!

I've been asked several times times recently (by various people) to explain FPS/ticktimes/clientrates/lag etc., so I thought I'd just make an epic wall of text post then refer people here, to save me repeating myself.

Firstly it is technical and not for everyone. If you're a masochist and actually interested then carry on!





I've been asked to explain the magic that is tickrate, after witnessing a convo where 90% of the people involved where just plain wrong It's a complicated area, which is probably why there's a few misconceptions.

Firstly Tickrate: bigger does not equal better. It does not improve your ping.

Tickrate is essentially the number of 'frames per second' that the server runs at. The default in chivalry used to be 30, it's currently recommended to be 60. A tickrate of 30 means the server is doing 30 frames of processing every second - player movements, weapon positions, me teabagging amixy etc.,

So working in milliseconds (obviously 1 second = 1000 milliseconds), if we set a server rate of 25 the ticktime is the time between updates e.g. 1000 / 25 (<= the tickrate) = 40 milliseconds. So in this regard a tickrate of 25 gives 40 milliseconds between each single update on the server. Each single update is called a frame.

So we've worked out processing time on the server, sadly we're not all gaming on a lan, so there's also communication time to and from the server. If you open a command prompt and ping a server you might get a ping of say 10-30ms if you're located reasonably close (same country) as the server. This ping time is the time in milliseconds for data to go from your computer to the server and back again.

When we're playing games, we're not just sending data backwards and forwards, we also have to wait for the server to process that data. If for example my ping in dos (for just purely sending data) is 35ms (and just to confuse things internet traffic is often asyncronous - it may take different routes on the way back with a different time e.g. tranmission of data could be 15ms, receiving data by a different route could be 20ms, therefore totalling 35ms)

So in chivalry sending on my connection above, sending data to the server takes around 17.5ms then we have the server processing time (from a few paragraphs up) of 40ms then we have time to send data back, 17.5ms again. So my ingame ping is 75ms

This is one of the areas where people go "but I ping the server (in dos), I get 20ms but it's showing a ping of 100" - a dos ping and the chivalry pings are different things.

But wait! that's too easy.

We've assumed that data takes 17.5ms to reach the server and then is processed at the end of a full tick. This doesn't happen. If the data reaches the server at the exact same time as a new server side frame then the above numbers add up. However if a server frame has just been processed a new frame won't be rendered for another 40ms (since at tickrate of 25, we get an update on the server every 40ms).

If however our data reaches the server and is halfway between a frame (and we know it's 40ms between each frame at tickrate 25), the total would be 17.5+20+17.5 = a ping of 55ms. So what you'll notice here is the lower the tickrate, the more potential for variable pings there is.

The other thing about dos pings - it's the time taken to send/receive data, but it's also dependant on the amount of data. A dos ping usually sends 32 bytes of data. Sod all basically. Chivalry sends a lot more data. Look at the difference in pings if you do a ping -l 32 (default 32 bytes) and ping -l 1024 (1k). Anyway I digress..

So this brings us neatly onto netspeed. The netspeed is the amount of data that your client computer will send to the server every second. A netspeed of 2048 means you're sending 2048 bytes of data (2KB) to the server every second. This rate is negotiated with the server. If the server receives 2KB of data per second, it assumes it can reply with 2KB of data per second - so even if the server netspeed is higher, you'd get 2K/ps back. The server can also overide client netspeeds, so if you set a netspeed of 100000000 the server won't reply at this speed.

Netspeed is directly related to Framerate. Frames per second. The default amount of data that chivalry sends and receives in a packet is 64 bytes. Say we set a netspeed of 4000. We'll end up with 4000/64 = 62.5FPS as a maximum value.

So now I'll go set a client netspeed at 30000 so 30000/64 = a maximum framerate of 468! This simply doesn't work. Your machine also needs to do things, such as rendering the actual game! Aside from the fact that your computer probably couldn't handle this, you're probably using a monitor that supports 66hz/75hz or more likely with us gamers, we're running 100hz/120hz. The means the monitor can only update at a maximum of 120 times per second. The game settings above, even if they weren't impossible from a game architecture point of view or from a server constrainment point of view would be 468 times per second, which would still not be possible.

So I've talked about netspeed, however the netspeed on your computer and the netspeed of the server can be different values. From a serverside we also have to consider the client rate. If it was just me connecting to a server both me and the server could have a really high netspeed. However the server also has to connect to other clients. The default client rate on chiv is 20000

If I theoretically spin up a 10 slot server on my own computer, but on an old ADSL line running at 512kbs up, 512kbs down as were common around 2005, this is essentially 64KB per second up and down. I would set a client rate of (64000 = 64K in bytes roughly) 64000/10 (the max number of clients) = 6400 asa netspeed is optimal to limit packet loss. Setting this server side would then also force a client to a netspeed between 2000 and the max of the server.

If we take the default values of chiv (20000 bytes per client per second), our 50 slot servers consume bandwidth to the tune of 1MB per second UPSTREAM (as in sending data to the client connections, not receiving it). This is a good point to remind people not to confuse mbps that the broadband providers love using and actual megabytes per second

Sooo let's say I set a client netspeed of 5000 and the server is running at 20 ticks. I'm allowed to receive 5000/20 = 250bytes of data per tick. Is this a problem? On a 10 slot server, probably not. On a 50 slot server, definitely: as the number of players on a server increases so does the amount of data generated to track their positions and things they're doing.

Anyway we then set the server tickrate to 40, now I can receive 5000/40=125 bytes per tick. Less data but a bit more frequently. This causes problems if the server needs to send more data aboutplayer positions than it can fit in the 125bytes of data. Data from the players furthest away is culled. We'll get onto pawn relevancy another day (!). If you set the tickrate too high, layers will begin to be seen to teleport around as you're no longer sent regular updates on where they are.

Messing with netspeeds. Sadly this will affect how often ghost hits happen and failed blocks. If we set a netspeed of 500 at 30 ticks on the client it's 500/64 = 8 updates per second to the server while the server, at tickrate 30 is doing 30 updates per second, meaning the server will put you in the same place 4 times in a row but it receives another update.

Packetloss can also have odd effects, the server believes the client data it receives. There are limits to this: if a player is location A in one tick and location B the next tick, there's some arbitrary calculations of whether this is possible. If point B is halfway across the map, the server will issue a netID ban for speedhacking.

So just to reiterate, tickrate is the tickrate of the server. FPS is the framerate of your client. Client framerates can be limited by the client netspeed or by the server netspeed over-ruling the client settings.

The maths part!

F6 ping is a "dos ping + 1000/tickrate + 0.5x1000/FPS"

this is the time it take data to get from server> client>server + 1000/tickrate (1000 being 1 second in ms, since tickrate is measured in ticks per second) + 0.5xtickrate - this is the average processing time. The server might receive data just after a frame has been rendered, it might receive it halfway through the frame, it might receive it just before a frame is about to be processed. This is essentially the client>server>client responsetime

Next is the F1 ping "dos ping + (1000/fps + 0.5*1000/tickrate)x0.5"
This is a client>server>client response time. Server pings the client, client waits a frame to answer (1000/fps) and the server again needs an average half-tick to process the reply (0.5*1000/tickrate)

So what's the ideal settings? In a perfect world the clients would be synced to the server, sending all their data at point in a frame where we have just enough time to process it before the frame end. In real life this doesn't happen.

Assuming you've got a fuck off sized server (in CPU/Memory) and you have sufficient bandwidth, the server tick time should be set to provide the optimal balance of processing time based on the typical pings of the average players. We can tally up the 50 players, work out the average pings, but we can't necessarily work out their own bandwidth - they might be on 100mb fibre, they might be AOL dialup users. They may even have tinkered with their own clientrates.

While we can do some maths and work out generalisations, often the best method is to adjust the ticktime on a server ans see what effect is has on the majority of typical players. Some may find a change improves their game, others may find it makes it laggier, the key is striking a balance that's good for the majority.

Phew.

The TLDR: Inceasing or lowering the tickrate effects gameplay. High tickrate = Higher CPU Usage and Higher Bandwidth. This is why high tickrate servers often cost more. Higher tickrates do not equal better servers, often the reverse is true. Setting high clientrates and netspeeds on a client get over-rided by the server. The best tickrate of the server is semi-dependant on the average client latencies and bandwidth

[TurboMidget]

Pff, that's not maths. It still has logical numbers in it.

[MonkeyFiend]

Pff, that's not maths. It still has logical numbers in it.

I could try to rephrase it in the form of a regular expression if that'd be better?

[AsDeR]

Pfft, stop with all the gibberish and fix the lag!

[TurboMidget]

I could try to rephrase it in the form of a regular expression if that'd be better?

Heavens no

I once thought Laplace theory looked scary but having looked through that stuff just now... It's from another world. Hell perhaps. Glad I don't have to work with it.

[amixy]

"me teabagging amixy"

gee thanks