Server tick rate

Discussions about Servers
User avatar
sektor2111
Godlike
Posts: 5431
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Server tick rate

Post by sektor2111 » Sun Apr 04, 2021 5:05 pm

I must be agree here... all time I tried to point people at TESTING these. UT has internal functions for this task, all need is dropping them into a mutator.

I witnessed a tick-rate configured at 60, but in presence of 16 players all went to 18-20 due to fascinating long chain arrays computing stats and other arrays which majority of players did not care about - it's a 4 CPU Cores win based machine. What Core.dll is reporting that it's the reality from machine at UE1 Level - the rest is OS, Uscript might be different - even LOWER at this point... I did not see said report in Linux yet...

User avatar
Hitman
Skilled
Posts: 181
Joined: Mon Aug 16, 2010 11:01 am
Location: Sweden

Re: Server tick rate

Post by Hitman » Mon Apr 05, 2021 12:56 pm

No one mention if your servers run under Linux or windows and witch windows, I think that plays a big part to.

User avatar
sektor2111
Godlike
Posts: 5431
Joined: Sun May 09, 2010 6:15 pm
Location: On the roof.

Re: Server tick rate

Post by sektor2111 » Mon Apr 05, 2021 3:34 pm

Linux or Windows these must be tested with C++ natives, Uscript is not that relevant if it's based on tick. By example at NfoServers that "win" machine (it's a VDS) has tick-rate reported by natives a bit faster than tick-rate reported by UScript for reasons which I cannot explain.
I have to admit that strong machines hosting 1 on 1 games might be better in all the way capable for real high tick-rates.

And now the techs - which I tested so far.
There is a command that can be sent from UScript and log captured as string called MEMSTAT.
This is showing amount of memory taken by UT compared with the rest - we have to take in account maximum amount which UT can handle...

Code: Select all

	local string Status, CrTick, CfTick;

//	log ("Triggerring");
	status=Level.ConsoleCommand("MEMSTAT");
	if ( bLog )
		log("Load ="$Right(Status,4)$" at "$Level.Game.NumPlayers$" Players.",'MemoryStatus');
All status can be re-logged not only a fragment of interest.
Then in the same function... GETMAXTICKRATE GETCURRENTTICKRATE

Code: Select all

	CrTick = Level.ConsoleCommand("GETCURRENTTICKRATE");
	CfTick = Level.ConsoleCommand("GETMAXTICKRATE");

	Status="Current Tick-Rate = "$CrTick$", Max Tick-Rate = "$CfTick;
	if ( bLog )
		log(Status,'TickState');
	if ( bBroadCast )
		MyBroadCastMessage("Tick-Rate Actual/Config = "$int(CrTick)$"/"$int(CfTick)$" ticks per second.");
What was reported in a high load moment was pretty closer to reality, players could feel the loss of performance without to be experts trained at Oxford.
Report can be done in a slow state code not each tick, just from time to time - a configurable time. Of course, strategy can be coded different, assigned to a mutate command, etc. Injecting userflags also shows if server it's under-resourced and admin is hypocrite pointing finger at player when his machine used it's an overloaded wreck unable to sustain a constant tick-rate or physically won't ever reach at 70-80.