Server tick rate
Server tick rate
I've seen this subject discussed elsewhere but never seen a conclusive answer.
Server admins, what tick rate do you use and why?
My current settings.
NetServerMaxTickRate=45
LanServerMaxTickRate=35
Server admins, what tick rate do you use and why?
My current settings.
NetServerMaxTickRate=45
LanServerMaxTickRate=35
Re: Server tick rate
This will be for me the most interesting topic when 469 comes out.
NewNet recommends a tickrate of 65.
The 469 release notes mention server tickrates will be set to 50.
http://utgl.unrealadmin.org/Patch/ReleaseNotes.htm
Most servers are set to 100 even with newnet.
I think the default plain out of the box is 30.
NewNet recommends a tickrate of 65.
The 469 release notes mention server tickrates will be set to 50.
http://utgl.unrealadmin.org/Patch/ReleaseNotes.htm
Most servers are set to 100 even with newnet.
I think the default plain out of the box is 30.
Last edited by esnesi on Mon Dec 16, 2019 10:18 pm, edited 2 times in total.
Re: Server tick rate
When shooting monsters sometimes they were not there where players saw them but a bit aside (especially shooting with Minigun). Changing NetServerMaxTickRate from 20 to 30 solved that.
"Multiple exclamation marks," he went on, shaking his head, "are a sure sign of a diseased mind." --Terry Pratchett
- Chamberly
- Godlike
- Posts: 1963
- Joined: Sat Sep 17, 2011 4:32 pm
- Personal rank: Dame. Vandora
- Location: TN, USA
- Contact:
Re: Server tick rate
Copied from discord ut-server-help... cuz no one seem to pay attention.
2:58 PM] yg.: Question. I have UT running on a windows machine with TF2.TickFix. the packets are very inconsistent - 30ish to 45 maybe. how could I possible fix this?
[4:04 PM] CacoFFF: @yg.
As far as I'm concerned, tickfix changes the operating system's timer resolution
[4:05 PM] CacoFFF: In Windows XP and server 2003, that value was 16 milliseconds.
[4:05 PM] CacoFFF: As of Windows 7/8 I believe, that was changed to 1 millisecond.
[4:05 PM] CacoFFF: (My Windows Server 2012 came on 1.007 on stock)
[4:05 PM] CacoFFF: So tickfix is really unnecessary on any operating system post Windows 8
[4:08 PM] CacoFFF: Even a one millisecond timer resolution can go against your ideal settings.
[4:08 PM] CacoFFF: Consider a 65 tickrate server.
[4:08 PM] CacoFFF: (Like uk siege)
[4:09 PM] CacoFFF: The REAL tickrate is in fact 66.7
[4:09 PM] CacoFFF: 1000/65=15.384
[4:10 PM] CacoFFF: Windows OS's Sleep API takes values in milliseconds, no fractions.
[4:10 PM] CacoFFF: So it's passing 15
[4:10 PM] CacoFFF: 1000/15=66.7~
[7:28 PM] yg.: I see. Will try without it tomorrow then
[7:28 PM] yg.: but it shouldn't make it worse, should it?
[8:02 PM] CacoFFF: It shouldn't make a difference at all on a newer operating system.
[8:02 PM] CacoFFF: If the tickrate is jumping like crazy, it's something else.
[8:02 PM] CacoFFF: You'd have to profile the server using the INJECT USERFLAG 1 INJECT USERFLAG 0 command
[8:03 PM] CacoFFF: act, net values printed will indicate the time in milliseconds the server takes to process a frame.
3:32 PM] CacoFFF: Notice to server admins:
If you're hosting a server for competitive/pug games, you'll want to change this option to zero
[IpDrv.TCPNetDriver]
KeepAliveTime=0
3:33 PM] CacoFFF: More info on why (to disable the following):
https://en.wikipedia.org/wiki/Nagle%27s_algorithm
- Feralidragon
- Godlike
- Posts: 5493
- Joined: Wed Feb 27, 2008 6:24 pm
- Personal rank: Work In Progress
- Location: Liandri
Re: Server tick rate
It also goes down to the game speed.
If you have a game at 150% speed instead of the normal 100%, it's probably in your best interest to increase the tick rate by at least 50% as well, since at higher game speeds the distance covered by a player within the same real time is larger, especially when dodging, jumping and falling, creating noticeable gaps that even simple linear interpolation from a lag compensation mod might not cover properly, making you missing shots you would otherwise hit.
Many other games (shooters) with a similar game speed to this one have problems like this, as companies generally go with the cheapest solution at 20 or 30 fps.
Apex runs at 20fps on the server side, so players miss a lot more shots than they should when players are moving very fast, especially at distance (sliding, ziplining, etc), which has been a hot topic over there.
Fortnite runs at 30fps, but since it's a much slower paced game in terms of movement, 30fps seems to be good enough for all shots to register properly, and for movement to flow well enough.
Meaning that depending on the kind of server you're creating, 30fps may suffice if you're creating a PvE game server (MH, coop, perhaps even BT), since you're up against slower movement overall (monsters, the map itself), whereas for a PvP game server, 30fps is generally too low for a game like UT99, since players move much faster, especially relative to one another (twice as fast at the very least), so something like 60fps will produce a better experience.
Generally higher tick rates will smooth out the movement and increase hit detection accuracy on the server, and that translates to a better experience, especially for better players, but that's of course at the cost of CPU (2x the tick rate is about 2x the CPU cost, keep that mind).
Furthermore, depending on the weapons used (standard weapons, ZP, NN, etc), you may run into some issues at low tick rates, for weapons that are highly dependent on the tick rate (such as the default minigun), which is also a rampant problem with many custom mods which were not made with tick rate in mind, due to the way they use and increment their own timers using tick time (generally the wrong way, creating differences with different tick rates).
Also, the more the tick rate deviates from the average frame rate from the players themselves, the bigger the error of positioning of some actors.
I would wager that most players still run the game at around 60fps.
For instance, any accelerating actor, be it a rocket in a defined path, or a falling rock, grenade or translocator target, anything with acceleration at all of any kind, will have an error in its positioning between the server and the clients, which will grow the longer that actor lasts, since non-linear physics (such as that applying an accelerating force, such as gravity) seems to be calculated linearly per tick, rather than non-linearly over time as it should from a physics standpoint, and as a result, over time the position of the actor in the client will mismatch more and more the real position in the server, meaning that something may not be at all to you where it actually is in the server, the tick rate difference being the main driver for that.
However, most of these actors do not last enough time in a server for this to be noticeable (even I only noticed when I ran into these issues with NW3 itself), since generally these projectiles are fired at a relatively close range.
But at long range, you start to notice these effects, especially if the server is updating 3 times slower than your client (20 tick rate vs 60fps on the client).
But there's a point where increasing the tick rate won't give any noticeable difference, namely when it surpasses every player's own tick rate (frame rate), or when it's over the network frequency of the most updated actor (the default network update frequency of actors is 100 times per second replication-wise in an online game), or even when the data sent as a direct result of increased tick rate surpasses the amount of available bandwidth of the server.
This is all, of course, from a strictly technical point of view, based on my own experience toying with tick rate for mod making alone.
I am not an admin, never was, so I don't have that hands on experience to tell you what the optimal tick rate would really be, the above are just generally some of the drivers that you should take into account when choosing and tweaking it.
If you have a game at 150% speed instead of the normal 100%, it's probably in your best interest to increase the tick rate by at least 50% as well, since at higher game speeds the distance covered by a player within the same real time is larger, especially when dodging, jumping and falling, creating noticeable gaps that even simple linear interpolation from a lag compensation mod might not cover properly, making you missing shots you would otherwise hit.
Many other games (shooters) with a similar game speed to this one have problems like this, as companies generally go with the cheapest solution at 20 or 30 fps.
Apex runs at 20fps on the server side, so players miss a lot more shots than they should when players are moving very fast, especially at distance (sliding, ziplining, etc), which has been a hot topic over there.
Fortnite runs at 30fps, but since it's a much slower paced game in terms of movement, 30fps seems to be good enough for all shots to register properly, and for movement to flow well enough.
Meaning that depending on the kind of server you're creating, 30fps may suffice if you're creating a PvE game server (MH, coop, perhaps even BT), since you're up against slower movement overall (monsters, the map itself), whereas for a PvP game server, 30fps is generally too low for a game like UT99, since players move much faster, especially relative to one another (twice as fast at the very least), so something like 60fps will produce a better experience.
Generally higher tick rates will smooth out the movement and increase hit detection accuracy on the server, and that translates to a better experience, especially for better players, but that's of course at the cost of CPU (2x the tick rate is about 2x the CPU cost, keep that mind).
Furthermore, depending on the weapons used (standard weapons, ZP, NN, etc), you may run into some issues at low tick rates, for weapons that are highly dependent on the tick rate (such as the default minigun), which is also a rampant problem with many custom mods which were not made with tick rate in mind, due to the way they use and increment their own timers using tick time (generally the wrong way, creating differences with different tick rates).
Also, the more the tick rate deviates from the average frame rate from the players themselves, the bigger the error of positioning of some actors.
I would wager that most players still run the game at around 60fps.
For instance, any accelerating actor, be it a rocket in a defined path, or a falling rock, grenade or translocator target, anything with acceleration at all of any kind, will have an error in its positioning between the server and the clients, which will grow the longer that actor lasts, since non-linear physics (such as that applying an accelerating force, such as gravity) seems to be calculated linearly per tick, rather than non-linearly over time as it should from a physics standpoint, and as a result, over time the position of the actor in the client will mismatch more and more the real position in the server, meaning that something may not be at all to you where it actually is in the server, the tick rate difference being the main driver for that.
However, most of these actors do not last enough time in a server for this to be noticeable (even I only noticed when I ran into these issues with NW3 itself), since generally these projectiles are fired at a relatively close range.
But at long range, you start to notice these effects, especially if the server is updating 3 times slower than your client (20 tick rate vs 60fps on the client).
But there's a point where increasing the tick rate won't give any noticeable difference, namely when it surpasses every player's own tick rate (frame rate), or when it's over the network frequency of the most updated actor (the default network update frequency of actors is 100 times per second replication-wise in an online game), or even when the data sent as a direct result of increased tick rate surpasses the amount of available bandwidth of the server.
This is all, of course, from a strictly technical point of view, based on my own experience toying with tick rate for mod making alone.
I am not an admin, never was, so I don't have that hands on experience to tell you what the optimal tick rate would really be, the above are just generally some of the drivers that you should take into account when choosing and tweaking it.
- sektor2111
- Godlike
- Posts: 6410
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: Server tick rate
Between 25-30 - I have reasons for that.
Like Barbie said, 20 it's not for MH (multi-games here), ignoring those smarts with tutorials from the past - they were not playing with monsters and miniguns after all.
Other direction: A way too fast tick-rate will miss some lightning effects in game - also here I was tracking one of my maps. In servers done by myself everything works almost like Off-Line, in others those effects are like NONE.
Note: Admins should have a "test-map" with all kind of lightning effects and quick things and see how do they look like On-Line - you should not ask from an under-resourced server what cannot be delivered.
Like Barbie said, 20 it's not for MH (multi-games here), ignoring those smarts with tutorials from the past - they were not playing with monsters and miniguns after all.
Other direction: A way too fast tick-rate will miss some lightning effects in game - also here I was tracking one of my maps. In servers done by myself everything works almost like Off-Line, in others those effects are like NONE.
Note: Admins should have a "test-map" with all kind of lightning effects and quick things and see how do they look like On-Line - you should not ask from an under-resourced server what cannot be delivered.
Re: Server tick rate
With that i am also saying that there are alot recommended values.esnesi wrote: ↑Mon Dec 16, 2019 9:17 pm This will be for me the most interesting topic when 469 comes out.
NewNet recommends a tickrate of 65.
The 469 release notes mention server tickrates will be set to 50.
http://utgl.unrealadmin.org/Patch/ReleaseNotes.htm
Most servers are set to 100 even with newnet.
I think the default plain out of the box is 30.
Now with Chamberly and Higor recommendation we also got 66.7 in the mix.
It would be nice that when 469 comes out, a final recommendation gets noted for servers with and without newnet/zp and such.
Re: Server tick rate
He basiscally says to keep it default at Windows servers.
And put it slightly more up on Linux servers with an asterisk.
NewNet isn't mentioned in that wiki article.
And put it slightly more up on Linux servers with an asterisk.
NewNet isn't mentioned in that wiki article.
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 UT 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 pingspikes, 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
Important: the above statement about Linux servers is not completely true, read the Addendum for more information.
- sektor2111
- Godlike
- Posts: 6410
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: Server tick rate
Bingo ! Exactly this is what I WON'T ever do, not for MonsterHunt and... I did not play any MH game with TNSE for showing him what is about at that 20 stupidity. The rest of images are... irrelevant. My machines weren't so stable at 12-15 tick-rate, actually they were crashing quickly, interval between frames it's way too big increasing ping response and it's not a smoother game at all.
- Feralidragon
- Godlike
- Posts: 5493
- Joined: Wed Feb 27, 2008 6:24 pm
- Personal rank: Work In Progress
- Location: Liandri
Re: Server tick rate
Another thing to take into account when choosing the right tick rate for your server, is understanding that the chosen tick rate also affects latency (ping).
It doesn't affect the network latency itself directly (the network latency between a client and the server), instead it affects the "real" practical latency concerning replication of data from and to the client, since the game will only send data at the end of each tick, and receive data at the start of each tick, and while the game is "ticking" or "sleeping" between ticks, no data is being sent to anyone, so you only receive data from a server up to the same frequency as the tick rate, and also your client only sends data up to the frequency of your own frame rate.
As such, if you use the default tick rate of 20, no matter how low the network latency is between a client and a server, the network latency may as well be 0ms, but the real latency will be about 50ms at minimum (1000ms / 20), and cannot go any lower.
With a tick rate of 30, the lowest latency would be about 33ms, and with a tick rate of 60 it would be around 17ms.
Which is more the reason to keep a PvP server with a tick rate of at least 60, to keep pings as low as possible if the clients are close enough to the server and have a good connection with a good routing, whereas PvE servers can perfectly stay at 30.
It doesn't affect the network latency itself directly (the network latency between a client and the server), instead it affects the "real" practical latency concerning replication of data from and to the client, since the game will only send data at the end of each tick, and receive data at the start of each tick, and while the game is "ticking" or "sleeping" between ticks, no data is being sent to anyone, so you only receive data from a server up to the same frequency as the tick rate, and also your client only sends data up to the frequency of your own frame rate.
As such, if you use the default tick rate of 20, no matter how low the network latency is between a client and a server, the network latency may as well be 0ms, but the real latency will be about 50ms at minimum (1000ms / 20), and cannot go any lower.
With a tick rate of 30, the lowest latency would be about 33ms, and with a tick rate of 60 it would be around 17ms.
Which is more the reason to keep a PvP server with a tick rate of at least 60, to keep pings as low as possible if the clients are close enough to the server and have a good connection with a good routing, whereas PvE servers can perfectly stay at 30.
Re: Server tick rate
It seems actual tick rate is less than normal, or, maybe the way it was measured is incorrect:
- With standard engine in Windows: https://i.postimg.cc/bvKHD3x4/tr-window ... engine.jpg
- With XC_Engine in Linux: https://i.postimg.cc/Jz0bp9K9/tr-linux-xc-engine.jpg
- With standard engine in Windows: https://i.postimg.cc/bvKHD3x4/tr-window ... engine.jpg
- With XC_Engine in Linux: https://i.postimg.cc/Jz0bp9K9/tr-linux-xc-engine.jpg
- sektor2111
- Godlike
- Posts: 6410
- Joined: Sun May 09, 2010 6:15 pm
- Location: On the roof.
Re: Server tick rate
Bump: Note after a two in one check
I have currently two things pointing almost to the same direction with regard to tick-rate, one it's calculated with UScript using a small math and Getting configured tick-rate from INI - part of some MH2 which I did times ago. Purpose was decreasing computing monsters number at low tick-rate when server has a lot of load.
The other method was a toy checking memory load and Tick-Rate using native response at command "GETCURRENTTICKRATE".
From UnGame.cpp found through resources and links posted in this forum... and UnEngineWin.h
I ran then this "other" method combined with that MH2 and both of them were extremely closer 25 VS 24 and randomly 24 vs 24 (rounded) at a tick-rate configured at 25.
If you ask why 25 ? NFoServers have some tools in their servers and tick-rate reported there is mainly stable at 22. When I added 30, they gave me 25. MH2 won't update monsters often at that tick-rate, it's what I could do in MH2 as add-on for a stable and smoother game as much as I could but without to know limitations from some rented services. This is running XC_Engine v24. I did not write a checker using XC_Engine, maybe it doesn't worth wasting time as long as two other different things returned similar results.
As a personal conclusion, I believe that in certain rented services, they have restrictions or whatever tools capping resources usage and if you think that you have a real high tick-rate over there you can keep dreaming on. Rented server boxes managed by them are way restrictive in options, if you have "big" plans there it would be wise to check what it's being accepted by your service before lying yourself.
If you need a little toy using internal natives for this task compatible with plain UT, configurable for printing results in logs and/or printing messages on screen, and interval for these print tasks, let me know - also it works from a defined number of players (testing during whatever charge) not permanent. It's a Server-Actor guaranteed unseen in network channels as reported by other commands which UT has. If you need another tool, a more Professional thing, then ask support from high-skilled coders.
I have currently two things pointing almost to the same direction with regard to tick-rate, one it's calculated with UScript using a small math and Getting configured tick-rate from INI - part of some MH2 which I did times ago. Purpose was decreasing computing monsters number at low tick-rate when server has a lot of load.
The other method was a toy checking memory load and Tick-Rate using native response at command "GETCURRENTTICKRATE".
From UnGame.cpp found through resources and links posted in this forum...
Spoiler
Code: Select all
UBOOL UGameEngine::Exec( const TCHAR* Cmd, FOutputDevice& Ar )
...
...
else if( ParseCommand( &Str, TEXT("GETCURRENTTICKRATE") ) )
{
Ar.Logf( TEXT("%f"), CurrentTickRate );
return 1;
}
else if( ParseCommand( &Str, TEXT("GETMAXTICKRATE") ) )
{
Ar.Logf( TEXT("%f"), GetMaxTickRate() );
return 1;
}
...
Spoiler
Code: Select all
static void MainLoop( UEngine* Engine )
{
guard(MainLoop);
check(Engine);
// Enter main loop.
guard(EnterMainLoop);
if( GLogWindow )
GLogWindow->SetExec( Engine );
unguard;
// Loop while running.
GIsRunning = 1;
DWORD ThreadId = GetCurrentThreadId();
HANDLE hThread = GetCurrentThread();
FTime OldTime = appSeconds();
FTime SecondStartTime = OldTime;
INT TickCount = 0;
while( GIsRunning && !GIsRequestingExit )
{
// Update the world.
guard(UpdateWorld);
FTime NewTime = appSeconds();
FLOAT DeltaTime = NewTime - OldTime;
Engine->Tick( DeltaTime );
if( GWindowManager )
GWindowManager->Tick( DeltaTime );
OldTime = NewTime;
TickCount++;
if( OldTime > SecondStartTime + 1 )
{
Engine->CurrentTickRate = (FLOAT)TickCount / (OldTime - SecondStartTime);
SecondStartTime = OldTime;
TickCount = 0;
}
unguard;
....
If you ask why 25 ? NFoServers have some tools in their servers and tick-rate reported there is mainly stable at 22. When I added 30, they gave me 25. MH2 won't update monsters often at that tick-rate, it's what I could do in MH2 as add-on for a stable and smoother game as much as I could but without to know limitations from some rented services. This is running XC_Engine v24. I did not write a checker using XC_Engine, maybe it doesn't worth wasting time as long as two other different things returned similar results.
As a personal conclusion, I believe that in certain rented services, they have restrictions or whatever tools capping resources usage and if you think that you have a real high tick-rate over there you can keep dreaming on. Rented server boxes managed by them are way restrictive in options, if you have "big" plans there it would be wise to check what it's being accepted by your service before lying yourself.
If you need a little toy using internal natives for this task compatible with plain UT, configurable for printing results in logs and/or printing messages on screen, and interval for these print tasks, let me know - also it works from a defined number of players (testing during whatever charge) not permanent. It's a Server-Actor guaranteed unseen in network channels as reported by other commands which UT has. If you need another tool, a more Professional thing, then ask support from high-skilled coders.
- Rubie
- Novice
- Posts: 9
- Joined: Tue Sep 20, 2016 9:46 am
- Personal rank: Old Man
- Location: Belgium
- Contact:
Re: Server tick rate
best tickrates are 30/28 , there is really no best or whatever..... (default will do the thing)
all lost words after all those years talking.
greets,
Rubie
all lost words after all those years talking.
greets,
Rubie
The more you know the more you know you are stupid