TNSe's boring page of Tickrate & Netspeed = facts

From: Subject: TNSe's boring page of Tickrate & Netspeed facts Date: Tue, 4 Jul 2006 18:19:37 -0500 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Location: http://www.clanvikings.org/tnse/utstuff.html X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.504 TNSe's boring page of Tickrate & Netspeed = facts

TNSe's boring page of Tickrate & = Netspeed=20 facts.

Small update, 10th July, 2002. Updates marked = with a=20 *.

Ok, I just wanted to write some boring facts about the boring = thing=20 that bores us all.
Tickrate &=20 Netspeed.

WHAT IS TICKRATE??!?!

What effect does it have in UT? Many ppl have seriously = interesting=20 views on this that easily can be put in parallel with the quotes = from=20 certain presidents in USA.

First of all. Higher tickrate does not improve ping. Very = common=20 misconception. What it ACTUALLY does, is to reduce the time = between=20 each time the server handles incoming data, and sends out new = data. So let=20 me explain it in more complex terms.

By first explaining what tickrate actually is, I hope to have = made you=20 so confused you will believe the rest of the things I write in = this=20 document.

Tickrate is actually VERY VERY COMPLEX! It is the "Frames Pr = Second" the=20 server is running at. Yes, it is so complex. A tickrate of 20 = means that=20 the server is doing 20 frames of action per second. To make it = even more=20 complex, lets just say, that it processes data 20 times a second. = (Player=20 movement, player firing, player deaths, player bitching, player = lagging,=20 and the other more unimportant things 20 times a second). So. 1 = Tick =3D 1=20 Frame. The server tickrate is the "framerate" at which the server = is=20 running on.

Ok, now that you are confused by the tickrate term, lets see = how far it=20 is between each tick update. since it says pr second, we will use = 1=20 second, which is 1000 milliseconds. it's Per. so we gotta divide=20 somewhere, let's try the following. 1000ms/20 =3D 50ms. OK! it = might seem=20 like there is 50 milliseconds between each tick. Let's try it the = other=20 way. 50ms * 20 =3D 1000ms. Oh yes, we reversed the equation and = got what we=20 started with. That means. A tickrate of 20, gives 50ms between = each update=20 on server.

PIIIIIIIIIIIIINGGGG!!!

Lets have a ping of 60 in DOS to a certain server. This means a = packet=20 of data uses 60 milliseconds to go from your superfantastic = computer to=20 the crappy tickrate 20 server in Uganda and back. In other = words.=20 Now because of the complexity of the net, this doesn't mean it = uses 30ms=20 to reach the server, and 30ms to travel back. (Asymmetric routing) = Someone=20 else will have to explain why this is so. But lets assume that = this is=20 actually the true thing this time. The data DOES use 30ms to = travel from=20 your computer to the server, and 30ms to reach your computer = again. Let's=20 put in some more numbers. The tickrate! We know that it's 50ms = between=20 each tick on server. So let's take worst case. The packet of data = we send,=20 uses 30ms to reach server. The server has just completed a tick = before the=20 data arrived, so the data has to wait for 50ms. Ok, data has = waited 50ms=20 and been processed, and now leaves the server for the client to = happily=20 enjoy. This takes another 30ms. So to add it up, the packet used = 30+50+30=20 =3D 110ms to travel from client to server, be processed on server, = and=20 return to client.

Another thing that affects result is your own framerate. Your = computer=20 will not handle data while it's busy telling the video card what = to show=20 you. A framerate of 100fps means that it's another 1000ms/100 =3D = 10ms=20 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=20 only UT sent that little :) The more data, the higher the ping = gets. Go=20 ahead and try it yourself.

PING <server> -l = 32 =20 Pings the server you choose with a 32byte = packet.

Example:

C:\>ping=20 ut.online.no -l 32

Pinging ut.online.no = [193.213.112.70] with=20 32 bytes of data:

Reply from 193.213.112.70: = bytes=3D32=20 time=3D35ms TTL=3D116
Reply from 193.213.112.70: = bytes=3D32 time=3D34ms=20 TTL=3D116
Reply from 193.213.112.70: bytes=3D32 = time=3D34ms=20 TTL=3D116
Reply from 193.213.112.70: bytes=3D32 = time=3D34ms=20 TTL=3D116

This looks good! Now lets try with a larger packet, like 512 = bytes.

PING <server> -l=20 512

Example:

C:\>ping=20 ut.online.no -l 512

Pinging ut.online.no = [193.213.112.70]=20 with 512 bytes of data:

Reply from 193.213.112.70: = bytes=3D512=20 time=3D156ms TTL=3D116
Reply from 193.213.112.70: = bytes=3D512=20 time=3D155ms TTL=3D116
Reply from 193.213.112.70: = bytes=3D512=20 time=3D155ms TTL=3D116
Reply from 193.213.112.70: = bytes=3D512=20 time=3D155ms TTL=3D116

Oops, it suddenly didn't look too good anymore right? But then = again, I=20 only have a fancy 64kbit isdn line. Mileage may vary depending on = your=20 connection.

NETSPEED!!!

What is netspeed good for? What does it do? Is Bin Laden dead?=20 Unfortunately, I can only answer the 2 first questions. Well, = seriously,=20 the 2 first questions is actually 1 question... Err, anyway.

The netspeed decides how much data you want to send to the = server each=20 second. A netspeed of 5000 will try to send 5000 bytes of data = each=20 second. And yes, for the smart ones out there that already guessed = it,=20 netspeed of 13690 will send 13690 bytes pr second. Also, it tells = the=20 server how much data you want to receive each second. The servers = seem to=20 not allow going under 2000, clients have a minimum of 500.

Some interesting aspect with the netspeed, is that it limits = your=20 framerate. Your maximum expected framerate online with netspeed = 5000 is=20 5000/64 =3D 78fps. You should not get more, you will often get = less. So why=20 /64 you ask? Well, it's kinda simple. Each time your computer does = an=20 update, it sends about 64 bytes of data. So the great doods at = epic=20 thought, let's do netspeed/64 and limit framerate that way, so the = client=20 does not exceed netspeed bytes sent pr second.

For those of you thinking:

OMG I GOTTA SET=20 NETSPEED TO 20000 = IMMEDIATELY!!"%!"#&"=A4/""11111

let me just inform you that your hardware probably can't hold = an even=20 20000/64 =3D 312fps average during an entire match anyway. Another = bottleneck here, is your internet connection. If you got a=20 state-of-the-art 9600 modem, it can only send and receive 9600/8 = =3D 1200=20 bytes/second anyway, and what happens if you exceed that limit, is = that=20 data must wait before it can be transmitted to/from you. This = causes the=20 wellknown "ping spike". So use netspeed to make sure your = connection does=20 not get overloaded and "spiked". If the spikes last too long, you = might=20 even get packetloss, since the packets get pissed off waiting in = queues=20 and kill themselves.

I found a nice trick myself. I put my netspeed to = refreshrate*64 (and=20 then + some for a nicer rounder number). I got 85hz refresh, *64 = =3D 5440,=20 so I set netspeed to 5500. This gives a nice flickerfree = experience when I=20 play online. To be bloody honest, I had been experimenting with = netspeeds=20 for a while until I found 5500 to be most pleasant. I didn't know = about=20 this *64 thing at the time. Weird coincidence or facts, you try=20 yourself.

Now I've said all about netspeed and effects on client to = server. Let's=20 take it the other way. What happens if the server wants to tell me = too=20 much. It can only tell me 5500 bytes pr second. The solution is = quite=20 simple. The server stops telling you stuff it feels is = nonimportant. This=20 has been carefully hac... errr balanced by the brainmonsters at = Epic to=20 give a great online gaming experience. Most important stuff = like=20 other players & bots have priority to be sent first. Then = comes less=20 important things, like projectiles & effects. So if the server = has too=20 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=20 air"-syndrome. If it has to wait sending stuff too long, you might = not=20 ever receive it. The result of this is you going dead from = invisible=20 stuff, this is often referred to as "WTF??!" by the players = affected.

SERVER=20 ADMINS, read this. You got an option in your .ini = file=20 under [IpDrv.TcpNetDriver] called MaxClientRate. The default value = of this=20 is usually 20000, which means, the client can maximum get 20000 = bytes=20 *FROM* server pr second. By reducing this value, you can actually = optimize=20 the server bandwidth. If you are planning on running a 10 player = server on=20 a 512/512kbit sdsl line, you will have 128kbyte up/down, so = setting=20 MaxClientRate to 128000/10 =3D 12800 means you will reduce the = chance of=20 having packetloss. This setting will also limit the client upload = rate,=20 forcing him to keep a netspeed between 2000 and=20 MaxClientRate.

SOOOO, LETS PUT THIS TOGETHER

As we all know, servers with HIGH tickrate is THE ownage thing = out=20 there. It's the best stuff that happened since man invented the=20 transistor. Or is it?

Lets say we got my reasonable netspeed of 5500. Each tick = on a=20 tickrate 20 server, I'm allowed to receive 5500/20 =3D 275 bytes = of data.=20 That is rarely a problem unless there is too many players or too = much spam=20 going on.

Ok, now lets try increasing the tickrate to 40. I'm suddenly = only=20 allowed to receive 5500/40 =3D 137.5 bytes of data pr tick. = This could=20 easily start to create trouble for me, as the server starts = deciding=20 things aren't important enough to send to me.

I'll tell you about the goodies of higher tickrates as well. = The first=20 thing is that the server responds more often (Tickrate 20, 50ms = between=20 each frame, Tickrate 40, 1000/40 =3D 25ms between each frame). And = the=20 second thing is that other players (and yourself of course, DUH!) = are=20 updated more often. with tickrate 40 vs 20, everything is actually = updated=20 twice as often!

You've probably been missing some images in this document. = WORRY = NO MORE, HERE=20 ARE SOME SUPER IMAGES!

A small debriefing of what these pictures mean. Each image of = my model=20 is 1 tick on the server. So that means, each time you see my = model, that=20 is where the server said I was.

So what does this mean? Hint: You can only hit people where the = server=20 say they are. Look at tickrate 5, and see, to hit me, you almost = gotta be=20 lucky. At Tickrate 100, you gotta be bad to avoid hitting me. Some = more=20 pics.

To say it again YOU HAVE TO HIT ONE OF THE "SHADOWS" OF MY = MODEL FOR=20 THE SERVER TO REGISTER A HIT.

And yes, hitting someone midair on tickrate 20 is harder than = with=20 tickrate 50. Definately. And 2 more

Tickrate = 20=20 | Tickrate=20 40

So now all of you are saying:

GEEZ, WE MUST=20 HAVE TICKRATE 100!!!!%&!#&!"#111

Nah, if you can't hit with tickrate 20, you have no skillz. = High=20 Tickrate =3D no skillz. Also remember what I said about data pr = second.=20 Higher tickrate =3D more data sent from server. You could start = getting=20 invisible rockets.

Now over to something really interesting. Let me show you the = pictures=20 first this time.

Tickr= ate=20 30, Netspeed 5500 | Tickr= ate=20 30, Netspeed 1000 | Tickra= te=20 30, Netspeed 500

And it's still the same, each "shadow" of my model =3D where it = is=20 possible to hit me. And yes. messing with your netspeed WILL = affect how=20 "easy" you are to hit on server. Notice how the server updates = your=20 animation several times while you still are in the same place. The = reason=20 for this, take example with 500 netspeed, is that you are only = sending=20 500/64 ~=3D 8 updates pr second to the server, while the server is = doing 30=20 updates pr second, which means it will put you in the same = position ~4=20 times in a row! Meanwhile, all other clients will see you fall in = a nice=20 curve, and shoot straight through you.

Here comes some pictures from a case where a player has = intermittant=20 outgoing packetloss (Movement data does not reach the server.) = This could=20 cause several problems, all ranging from total loss of data, to = data=20 coming in wrong order. All pictures were taken with Tickrate 30 on = the=20 server.

Tickrate = 30,=20 Packetloss, Pic 1 | Tickrate = 30,=20 Packetloss, Pic 2 | Tickrate = 30,=20 Packetloss, Pic 3 | Tickrate = 30,=20 Packetloss, Pic 4

Pic 1 shows clearly what happens when the client is having a = pure=20 outgoing packetloss, simply, packets do not reach server, and are = stopped=20 somewhere Pic 2 is interesting, since it shows that the player = with=20 packetloss is CLEARLY incorrectly offsetted compared to what MY = client is=20 predicting. As you see, the player with packetloss is actually a = lot=20 higher up than my client is showing. The cause for this could be = that the=20 packetloss player got packetloss just as he jumped, this means the = server=20 didn't register any jump before he had started, and therefore told = me too=20 late that he did jump. so the entire flight path has wrong timing. = Pic 3=20 is another example of what happens. Big holes in the movements. = Pic 4 as=20 well.

So what can be done with this? Nothing. This is due to the way = UT=20 behaves, it allows the client to control its own movement (to a = certain=20 degree) without server intervention. This is done to allow more = smoother=20 gameplay.If the client is too much out of order compared to what = server=20 means he should be, he will be moved back.

* Some people were missing an explanation for F1/F6 (stat net)=20 pings.
Here is a rude formula to show the relation of DOS Ping, = F1 Ping=20 and F6 ping. It is not overly accurate, but you will hopefully see = that=20 there is a relation between them.

f1 = ping =3D dos=20 ping + (1000/fps + 0,5*1000/tickrate)*0,5
f6 ping =3D dos ping = +=20 1000/tickrate + 0,5*1000/fps

Tickrate is the tickrate of the server, and fps is the = framerate of=20 your client. Remember that the framerate on clients can be limited = by=20 using netspeed. Netspeed 5500 gives ~85fps max.

For those of you who don't want a more indepth explanation of = these=20 formulas, skip over the following part.

The dos ping is used as a base for how long a packet needs to = travel=20 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=20 Server, at server it has to wait a tick before it is sent back to = client=20 (=3D 1000/tickrate). Then it is sent back to client, and client = cannot use=20 this reply until (in average) half the time it takes to render a = frame.=20 (0.5*1000/fps). F1 is Server->Client->Server response time. = Server=20 asks client for a ping reply, Client waits 1 frame to answer = (1000/fps),=20 and server needs in average half a tick to process the reply.=20 (0,5*1000/tickrate). And for some reason, DE/EPIC divided the time = this=20 takes in 2. (*0,5). (This can be found in the uscript code). Hope = this=20 confuses you who should have skipped this section.

SERVER=20 ADMINS, read this. Increasing or Lowering the = tickrate has=20 documented effect on the gameplay (heck, what do you think this = document=20 is about? :P). Also, I'd like to point out the following. Higher = tickrate=20 =3D higher CPU usage! So setting your blazing P-2 350MHZ 32player = max=20 superserver to tickrate 100 is rather a bad idea. With higher = tickrates,=20 the bandwidth requirements go up as well. I'd recommend keeping = tickrates=20 at their default if you want more than 10 players on the server... = A final=20 note to those running Linux servers. For some reason, the guys at = Loki=20 mindlessly translated the UT code from Win32 based to Linux = based=20 without really thinking over the sideeffects it had. Linux is not = as good=20 as Windows at something which I can't explain properly without = having=20 2million ppl rubbing penguins on my window telling me how I'm a = microsoft=20 lover. Back to the point. Linux isn't so exact at getting the = tickrate=20 correctly. This means a tickrate of 20 on a linux server might = actually be=20 more like 15... Which is why I'd nearly ask you linux phreaks to = either=20 get Win32 based server, or ... sigh, up the tickrate slightly. = Just for a=20 final note... WinNT4 SP6 based servers are the ones I like best. = They=20 provide stable gameplay. Win2k based servers give occational = pingspikes,=20 and Linux based servers can be a bit dodgy (stuff go through = people).=20 Never tried Mac Based servers. and Win98 based servers probably = gotta be=20 rebooted every day or so, most likely not a good alternative = :)

DOES TICKRATE AFFECT WEAPONS?

Good question. Answer is. Yes. The affected weapons = are

Enforcer
Sniper Rifle
Shock Rifle = Primary
Minigun
Pulse Gun=20 Secondary

Enforcer, Sniper & Shock are only affected in the way that = hitboxes=20 are more regularly updated (see pictures above). Also your aiming = angle is=20 used more often on the server, causing the entire thing to be just = more=20 accurate.

Now, the minigun is a nasty thing when it comes to = tickrate.=20 I'll simply put up a little pic here:

Minigun=20 Diagram

So what does this mean? Actually it's quite = simple, read the=20 stuff on the diagram. The minigun fires more or less bullets = depending on=20 the tickrate of the server. A tickrate of 20 will give you ~10=20 bullets/second, while increasing to 25 could theoretically give = you 12.5=20 bullets/second. a 25% increase in damage.35 tickrate gives about = 11=20 bullets/second. Remember though, this is entirely theoretical. The = tickrate is not perfect on the server, it will vary a bit. But = it's=20 interesting enough as it shows on the picture. Different tickrates = can be=20 used to manipulate the power of the minigun. This is one of the = reasons I=20 think tickrate should stay at a default of 20. Simply to avoid = minigun=20 being overpowered.

And what about the pulse gun? Aside from the more accurate hit = control,=20 it grows faster. Yup. You heard me. The pulse beam extends with 1 = segment=20 (it consists of 9) per tick. This means it will use 50ms*8 =3D = 400ms to=20 reach full length at tickrate 20. At tickrate 40, it will use = 25ms*8 =3D=20 200ms to reach full length. So if you are playing on a higher = tickrate,=20 the pulse secondary goes from being a close combat weapon, to = becoming a=20 very effective medium range weapon. Another thing is that the = Plasma=20 accumulates damage potential as long as it isn't in contact with = any=20 player. With higher tickrates, it can more often change state from = being=20 "in contact" and "not in contact", creating more damage as = result.

So I hope this can explain why minigun & pulse are more = effective=20 on lans... It's not only the lower ping & more often hit = registration=20 of the weapons, but also side effects from the higher default = tickrate of=20 35. I would suggest servers keeping the tickrate of 20 to avoid = messing up=20 the weapon balance.

OK, WHAT NOW!?!?

A ton of thanks to Mongo for telling me a bunch of stuff I = really=20 didn't have to know. Because of all this stuff he told me, I had = to write=20 this document just to save space in my head for more important = things. I=20 also hope he has learnt a lot himself from working with UT's = networking=20 code, atleast enough to avoid some of the worst pitfalls = encountered with=20 UT, in upcoming games :)

Also thanks to Garfield the NUBie (He hates being called NUB = for an=20 unknown reason) who always has to tell me not all germans are = bratwurst.=20 (Why do all germans believe that they aren't???) Also we have = discussed=20 tons of things tons of times. Usually ending up at the same = conclusion=20 every time. Ping stinks.

Bye.

=3D Spam will not = be accepted=20 at My Mail = Addy =3D=20
=3D Edited by membrane =3D