Sniper's Paradise!
Tickrate & Netspeed
What is tickrate?
What effect does it have in Unreal? First of all. Higher tickrate does not improve ping. Very common misconception. What it ACTUALLY does, is to reduce the time between each time the server handles incoming data, and sends out new data. So let me explain it in more complex terms.
Tickrate is actually Very complex! It is the "Frames Pr Second" the server is running at. Yes, it is so complex. A tickrate of 20 means that the server is doing 20 frames of action per second. To make it even more complex, lets just say, that it processes data 20 times a second. (Player movement, player firing, player deaths, player bitching, player lagging, and the other more unimportant things 20 times a second). So. 1 Tick = 1 Frame. The server tickrate is the "framerate" at which the server is running on.
Ok, now that you are confused by the tickrate term, lets see how far it is between each tick update. since it says pr second, we will use 1 second, which is 1000 milliseconds. it's Per. so we gotta divide somewhere, let's try the following. 1000ms/20 = 50ms. OK! it might seem like there is 50 milliseconds between each tick. Let's try it the other way. 50ms * 20 = 1000ms. Oh yes, we reversed the equation and got what we started with. That means. A tickrate of 20, gives 50ms between each update on server.
Ping
Lets have a ping of 60 in DOS to a certain server. This means a packet of data uses 60 milliseconds to go from your superfantastic computer to the crappy tickrate 20 server in Uganda and back. In other words. Now because of the complexity of the net, this doesn't mean it uses 30ms to reach the server, and 30ms to travel back. (Asymmetric routing) Someone else will have to explain why this is so. But lets assume that this is actually the true thing this time. The data DOES use 30ms to travel from your computer to the server, and 30ms to reach your computer again. Let's put in some more numbers. The tickrate! We know that it's 50ms between each tick on server. So let's take worst case. The packet of data we send, uses 30ms to reach server. The server has just completed a tick before the data arrived, so the data has to wait for 50ms. Ok, data has waited 50ms and been processed, and now leaves the server for the client to happily enjoy. This takes another 30ms. So to add it up, the packet used 30+50+30 = 110ms to travel from client to server, be processed on server, and return to client.
Another thing that affects result is your own framerate. Your computer will not handle data while it's busy telling the video card what to show you. A framerate of 100fps means that it's another 1000ms/100 = 10ms between each time it can handle data.
You thought that was all? You were wrong. Again. Of course :)
The DOS ping usually only sends a small packet, of like 32 bytes. If only Unreal sent that little :) The more data, the higher the ping gets. Go ahead and try it yourself.
PING <server> -l 32 Pings the server you choose with a 32byte packet.
Example:|
C:\>ping unreal.online.no -l 32
Pinging unreal.online.no [193.213.112.70] with 32 bytes of data: Reply from 193.213.112.70: bytes=32 time=35ms TTL=116 Reply from 193.213.112.70: bytes=32 time=34ms TTL=116 Reply from 193.213.112.70: bytes=32 time=34ms TTL=116 Reply from 193.213.112.70: bytes=32 time=34ms TTL=116 |
This looks good! Now lets try with a larger packet, like 512 bytes.
PING <server> -l 512
Example:|
C:\>ping unreal.online.no -l 512
Pinging unreal.online.no [193.213.112.70] with 512 bytes of data: Reply from 193.213.112.70: bytes=512 time=156ms TTL=116 Reply from 193.213.112.70: bytes=512 time=155ms TTL=116 Reply from 193.213.112.70: bytes=512 time=155ms TTL=116 Reply from 193.213.112.70: bytes=512 time=155ms TTL=116 |
It suddenly didn't look too good anymore right? But then again, I only have a fancy 64kbit isdn line. Mileage may vary depending on your connection.
Netspeed
What is netspeed good for? What does it do? The 2 questions is actually 1 question...
The netspeed decides how much data you want to send to the server each second. A netspeed of 5000 will try to send 5000 bytes of data each second. And yes, for the smart ones out there that already guessed it, netspeed of 13690 will send 13690 bytes pr second. Also, it tells the server how much data you want to receive each second. The servers seem to not allow going under 2000, clients have a minimum of 500.
Some interesting aspect with the netspeed, is that it limits your framerate. Your maximum expected framerate online with netspeed 5000 is 5000/64 = 78fps. You should not get more, you will often get less. So why /64 you ask? Well, it's kinda simple. Each time your computer does an update, it sends about 64 bytes of data. So the great doods at epic thought, let's do netspeed/64 and limit framerate that way, so the client does not exceed netspeed bytes sent pr second.
For those of you thinking:
I've got to set my netspeed to 20000!!
let me just inform you that your hardware probably can't hold an even 20000/64 = 312fps average during an entire match anyway. Another bottleneck here, is your internet connection. If you got a state-of-the-art 9600 modem, it can only send and receive 9600/8 = 1200 bytes/second anyway, and what happens if you exceed that limit, is that data must wait before it can be transmitted to/from you. This causes the wellknown "ping spike". So use netspeed to make sure your connection does not get overloaded and "spiked". If the spikes last too long, you might even get packetloss, since the packets get pissed off waiting in queues and kill themselves.
I found a nice trick myself. I put my netspeed to refreshrate*64 (and then + some for a nicer rounder number). I got 85hz refresh, *64 = 5440, so I set netspeed to 5500. This gives a nice flickerfree experience when I play online. To be bloody honest, I had been experimenting with netspeeds for a while until I found 5500 to be most pleasant. I didn't know about this *64 thing at the time. Weird coincidence or facts, you try yourself.
Now I've said all about netspeed and effects on client to server. Let's take it the other way. What happens if the server wants to tell me too much. It can only tell me 5500 bytes pr second. The solution is quite simple. The server stops telling you stuff it feels is nonimportant. This has been carefully hac... errr balanced by the brainmonsters at Epic to give a great online gaming experience. Most important stuff like other players & bots have priority to be sent first. Then comes less important things, like projectiles & effects. So if the server has too much to tell you, it will put it off until it sees you have enough bandwidth to receive it. Thus, you get the infamous "rockets out of thin air"-syndrome. If it has to wait sending stuff too long, you might not ever receive it. The result of this is you going dead from invisible stuff, this is often referred to as "WTF??!" by the players affected.
Server Amins, read this. You got an option in your .ini file under [IpDrv.TcpNetDriver] called MaxClientRate. The default value of this is usually 20000, which means, the client can maximum get 20000 bytes *FROM* server pr second. By reducing this value, you can actually optimize the server bandwidth. If you are planning on running a 10 player server on a 512/512kbit sdsl line, you will have 128kbyte up/down, so setting MaxClientRate to 128000/10 = 12800 means you will reduce the chance of having packetloss. This setting will also limit the client upload rate, forcing him to keep a netspeed between 2000 and MaxClientRate.
Lets put this all together
As we all know, servers with HIGH tickrate is THE ownage thing out there. It's the best stuff that happened since man invented the transistor. Or is it?
Lets say we got my reasonable netspeed of 5500. Each tick on a tickrate 20 server, I'm allowed to receive 5500/20 = 275 bytes of data. That is rarely a problem unless there is too many players or too much spam going on.
Ok, now lets try increasing the tickrate to 40. I'm suddenly only allowed to receive 5500/40 = 137.5 bytes of data pr tick. This could easily start to create trouble for me, as the server starts deciding things aren't important enough to send to me.
I'll tell you about the goodies of higher tickrates as well. The first thing is that the server responds more often (Tickrate 20, 50ms between each frame, Tickrate 40, 1000/40 = 25ms between each frame). And the second thing is that other players (and yourself) are updated more often. with tickrate 40 vs 20, everything is actually updated twice as often!
You've probably been missing some images in this document. WORRY NO MORE, HERE ARE SOME SUPER IMAGES!
A small debriefing of what these pictures mean. Each image of my model is 1 tick on the server. So that means, each time you see my model, that is where the server said I was.
Tickrate 5 | Tickrate 15 | Tickrate 20 | Tickrate 30 | Tickrate 40 | Tickrate 50 | Tickrate 100
So what does this mean? Hint: You can only hit people where the server say they are. Look at tickrate 5, and see, to hit me, you almost gotta be lucky. At Tickrate 100, you gotta be bad to avoid hitting me. Some more pics.
Tickrate 5 | Tickrate 20 | Tickrate 30 | Tickrate 40 | Tickrate 50 | Tickrate 100
To say it again YOU HAVE TO HIT ONE OF THE "SHADOWS" OF MY MODEL FOR THE SERVER TO REGISTER A HIT.
And yes, hitting someone midair on tickrate 20 is harder than with tickrate 50. Definately. And 2 more
So now all of you are saying:
We must have tickrate 100!!
Nah, if you can't hit with tickrate 20, you have no skillz. High Tickrate = no skillz. Also remember what I said about data pr second. Higher tickrate = more data sent from server. You could start getting invisible rockets.
Now over to something really interesting. Let me show you the pictures first this time.
Tickrate 30, Netspeed 5500 | Tickrate 30, Netspeed 1000 | Tickrate 30, Netspeed 500
And it's still the same, each "shadow" of my model = where it is possible to hit me. And yes. messing with your netspeed WILL affect how "easy" you are to hit on server. Notice how the server updates your animation several times while you still are in the same place. The reason for this, take example with 500 netspeed, is that you are only sending 500/64 ~= 8 updates pr second to the server, while the server is doing 30 updates pr second, which means it will put you in the same position ~4 times in a row! Meanwhile, all other clients will see you fall in a nice curve, and shoot straight through you.
Here comes some pictures from a case where a player has intermittant outgoing packetloss (Movement data does not reach the server.) This could cause several problems, all ranging from total loss of data, to data coming in wrong order. All pictures were taken with Tickrate 30 on the server.
Tickrate 30, Packetloss, Pic 1 | Tickrate 30, Packetloss, Pic 2 | Tickrate 30, Packetloss, Pic 3 | Tickrate 30, Packetloss, Pic 4
Pic 1 shows clearly what happens when the client is having a pure outgoing packetloss, simply, packets do not reach server, and are stopped somewhere Pic 2 is interesting, since it shows that the player with packetloss is CLEARLY incorrectly offsetted compared to what MY client is predicting. As you see, the player with packetloss is actually a lot higher up than my client is showing. The cause for this could be that the packetloss player got packetloss just as he jumped, this means the server didn't register any jump before he had started, and therefore told me too late that he did jump. so the entire flight path has wrong timing. Pic 3 is another example of what happens. Big holes in the movements. Pic 4 as well.
So what can be done with this? Nothing. This is due to the way unreal behaves, it allows the client to control its own movement (to a certain degree) without server intervention. This is done to allow more smoother gameplay. If the client is too much out of order compared to what server means he should be, he will be moved back.
* Some people were missing an explanation for F1/F6 (stat net) pings.
Here is a rude formula to show the relation of DOS Ping, F1 Ping and F6 ping. It is not overly accurate, but you will hopefully see that there is a relation between them.
f1 ping = dos ping + (1000/fps + 0,5*1000/tickrate)*0,5
f6 ping = dos ping + 1000/tickrate + 0,5*1000/fps
Tickrate is the tickrate of the server, and fps is the framerate of your client. Remember that the framerate on clients can be limited by using netspeed. Netspeed 5500 gives ~85fps max.
For those of you who don't want a more indepth explanation of these formulas, skip over the following part.
The dos ping is used as a base for how long a packet needs to travel forth & back. This is the minimum latency needed to complete a ping-pong. First I will explain F6, since it is simpler. F6 is the response time for Client->Server->Client. Client requests it from Server, at server it has to wait a tick before it is sent back to client (= 1000/tickrate). Then it is sent back to client, and client cannot use this reply until (in average) half the time it takes to render a frame. (0.5*1000/fps). F1 is Server->Client->Server response time. Server asks client for a ping reply, Client waits 1 frame to answer (1000/fps), and server needs in average half a tick to process the reply. (0,5*1000/tickrate). And for some reason, DE/EPIC divided the time this takes in 2. (*0,5). (This can be found in the uscript code). Hope this confuses you who should have skipped this section.
Server Admins, read this Increasing or Lowering the tickrate has documented effect on the gameplay (heck, what do you think this document is about?. Also, I'd like to point out the following. Higher tickrate = higher CPU usage! So setting your blazing P-2 350MHZ 32player max superserver to tickrate 100 is rather a bad idea. With higher tickrates, the bandwidth requirements go up as well. I'd recommend keeping tickrates at their default if you want more than 10 players on the server... A final note to those running Linux servers. For some reason, the guys at Loki mindlessly translated the unreal code from Win32 based to Linux based without really thinking over the sideeffects it had. Linux is not as good as Windows at something which I can't explain properly without having 2million ppl rubbing penguins on my window telling me how I'm a microsoft lover. Back to the point. Linux isn't so exact at getting the tickrate correctly. This means a tickrate of 20 on a linux server might actually be more like 15... Which is why I'd nearly ask you linux phreaks to either get Win32 based server, or ... sigh, up the tickrate slightly. Just for a final note... WinNT4 SP6 based servers are the ones I like best. They provide stable gameplay. Win2k based servers give occational and Linux based servers can be a bit dodgy (stuff go through people). Never tried Mac Based servers. and Win98 based servers probably gotta be rebooted every day or so, most likely not a good alternative
Does tickrate affect weapons?
Good question. Answer is. Yes. The affected weapons are
AutoMag
Rifle
ASMD Primary
Minigun
AutoMAg, Rifle & ASMD are only affected in the way that hitboxes are more regularly updated (see pictures above). Also your aiming angle is used more often on the server, causing the entire thing to be just more accurate.
Now, the minigun is a nasty thing when it comes to tickrate.
So what does this mean? The minigun fires more or less bullets depending on the tickrate of the server. A tickrate of 20 will give you ~10 bullets/second, while increasing to 25 could theoretically give you 12.5 bullets/second. a 25% increase in damage.35 tickrate gives about 11 bullets/second. Remember though, this is entirely theoretical. The tickrate is not perfect on the server, it will vary a bit. But it's interesting enough as it shows on the picture. Different tickrates can be used to manipulate the power of the minigun. This is one of the reasons I think tickrate should stay at a default of 20. Simply to avoid minigun being overpowered.
So I hope this explained why the minigun is more effective on lans... It's not only the lower ping & more often hit registration of the weapons, but also side effects from the higher default tickrate of 35. I would suggest servers keeping the tickrate of 20 to avoid messing up the weapon balance.
Credit to TNSe
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