PDA

View Full Version : Tickrate on UK server



Blackdeath
12-16-2015, 11:41 AM
I think It be interesting know how players are feeling with tickrate 100.

For me is too much, I've 60 hz monitor and my frame rate limit set 65. I can't increase this value at 100. Yes, not all have 144 hz.. :wallbash 35-40 missed packets every sec it's a big disadvantage. In addition, always IMHO, this aggressive tickrate can cause "lagfest" in server with 18-20 slots.

Surely with new host UK server runs better, but is improvable :)

soma
12-16-2015, 11:45 AM
you must have missed this discussion;

http://www.unrealkillers.com/f33/new-net-tick-rate-questions-timtim-6731/

Blackdeath
12-16-2015, 11:47 AM
you must have missed this discussion;

http://www.unrealkillers.com/f33/new-net-tick-rate-questions-timtim-6731/


OPS! :D

SAM
12-16-2015, 12:35 PM
Is it set to 100? Since when....

I will check when I get home.

Higor
12-16-2015, 01:44 PM
It's at 65, these ppl's got no idea what they're talking about.

Blackdeath
12-16-2015, 01:58 PM
It's at 65, these ppl's got no idea what they're talking about.


Really? Explain this


http://i63.tinypic.com/16c002x.jpg

Higor
12-16-2015, 02:15 PM
I'd rather trust what the server tells me directly.
2738

Blackdeath
12-16-2015, 02:59 PM
I'd rather trust what the server tells me directly.
2738


Ok i trust you :) Maybe smartctf bug.. On US all is fine

Higor
12-16-2015, 03:33 PM
This is the default Engine's userflags stats, the server will send messages to the client telling various interesting info.
The command is:
- INJECT USERFLAG parameter
The parameter is read using bitmasks.
0x01 = Base stats (00000001)
0x02 = Net cycles (00000010)
So, 1 means Base stats, 2 means Net cycles, 3 means both (00000011) just like any other value that has said bytes set to 1 (32 bit value, i only represented 8 here).

A good bind to quickly measure stats (may be flawed)
P=inject userflag 1|onrelease inject userflag 0

- r: MaxTickRate, zero in listen servers.
- cli: Number of connections, very high if server is under specific kinds of ddos.
- act: Time taken to process game update in a single frame (milliseconds), and (Amount of actors in level).
- net: Time taken to process relevancy loop and net update on clients (milliseconds)
The other ones are of little relevancy... except rpc/c, which may be an indicator that the server is calling too many functions on clients, a nice way to debug faulty mods.

if( Connection->UserFlags&1 )
{
// Send stats.
INT NumActors=0;
for( INT i=0; i<Actors.Num(); i++ )
NumActors += Actors(i)!=NULL;
FString Stats = FString::Printf
(
TEXT("r=%i cli=%i act=%03.1f (%i) net=%03.1f pv/c=%i rep/c=%i rpc/c=%i"),
appRound(Engine->GetMaxTickRate()),
NetDriver->ClientConnections.Num(),
GSecondsPerCycle*1000*ActorTickCycles,
NumActors,
GSecondsPerCycle*1000*NetTickCycles,
NumPV /NetDriver->ClientConnections.Num(),
NumReps/NetDriver->ClientConnections.Num(),
NumRPC /NetDriver->ClientConnections.Num()
);
Connection->Actor->eventClientMessage( *Stats, NAME_None, 0 );
}

EXTRA, These are XC_Engine stats (will help you recognize XC_Engine servers right away due to missing rpc/c):

- r: 1/DeltaTime of current frame, if this value jumps a lot then the tickrate is unstable (the measuring isn't too well rounded)
- cli: Connection count
- act: Actor processing time on last frame (actor count)
- net: Net processing time on last frame

if( Connection->UserFlags&1 )
{
if ( !NumActors ) //Prevent multiple UserFlag clients from using extra CPU cycles
for( INT ii=0; ii<Actors.Num(); ii++ )
NumActors += Actors(ii)!=NULL;
FString Stats = FString::Printf
(
TEXT("r=%i cli=%i act=%03.1f (%i) net=%03.1f pv/c=%i rep/c=%i"),
appRound( FrameRate),
NetDriver->ClientConnections.Num(),
GSecondsPerCycle * 1000 * ActorTickCycles,
NumActors,
GSecondsPerCycle * 1000 * NetTickCycles,
NumPV/NetDriver->ClientConnections.Num(),
NumReps/NetDriver->ClientConnections.Num()
);
Connection->Actor->eventClientMessage( *Stats, NAME_None, 0 );

}

Some interesting math:
- A second takes 1000 milliseconds.
- A frame can take up to 1000/TR ms before it becomes unstable (TR 100: a frame can take up to 10ms)
- Net+Act encompass over 95% of cpu cycles measured so it's accurate to say that Net+Act are what a frame took on the server.
- If Net+Act are higher than 1000/TR, then you have to lower the server tickrate to keep it stable.
The rules above can be worked around in several cases:
- Mod developers may manually specify an actor's update rate to a low value (4hz on a stat counter like SmartCTF) saving CPU cycles and allowing TR increase.
- Server admins can use tools that alter player's update rate (NetRateMod for example, alters based on a configurable table of player counts) and increase TR to values above 100.
(I'd totally run a 150 TR server using NetRateMod lol).

Other interesting detail in F6 stats:
- Channel: measures the amount of open channels in YOUR connection, there are three channel types (as of v451), there's a max of 1023 channels:
--- Control channel (index 0) which is the initial info sent between client and server to understand each other.
--- File channel, opened when server directly sends a file to you (XC_Core can send compressed files)
--- Actor channel, opened when the server is replicating an actor to your client.
Ideally those values sit between 150 and 300 on crowded servers, heavily modded ones can have up to 400 but anything going over 500 is a symptom of something not done well.
If channel count goes above 1023 you will start losing actors as the server won't be able to send them to you.
In some cases (v436 servers), that channel count can reach 1023 while you're joining and you'll be unable to receive your player... causing you to be unable to join the game (sitting in connecting...)
In other cases (v451 servers), you will be able to join but you won't receive important stuff like NPLoader, Nexgen controller and you will be kicked shortly.
If the server is using XC_Engine, all the actors belonging to the client will be highest in the prioritization and will take up important channels before other things, allowing you to join and login even the the channel list is saturated.

Chamberly
12-16-2015, 08:13 PM
Yeah 65.

Btw blackdeath... one of your siege map have a file mismatch with color, would you mind rebuilding it with a different name so no file mismatch come around on that?

Blackdeath
12-17-2015, 08:12 AM
Yeah 65.

Btw blackdeath... one of your siege map have a file mismatch with color, would you mind rebuilding it with a different name so no file mismatch come around on that?


Roger that :) Where is mismatch? I've just tested map and haven't noticed this issue

Chamberly
12-17-2015, 08:17 AM
Roger that Where is mismatch? I've just tested map and haven't noticed this issue

It's colors file. There is a colors.u and you have a colors.utx. So basically, you'd make a new file using a different name (like colors_bd like it's from you) and export all the one in colors.utx, and upload it to colors_bd (you may have to use a different texture name in order to successfully replace textures) and then do color replace... make sense?

Blackdeath
12-17-2015, 08:30 AM
It's colors file. There is a colors.u and you have a colors.utx. So basically, you'd make a new file using a different name (like colors_bd like it's from you) and export all the one in colors.utx, and upload it to colors_bd (you may have to use a different texture name in order to successfully replace textures) and then do color replace... make sense?

Mmm. I always used the same colors.utx file, why now It's causing msimatch?



EDIT: I've just tested other (my) "old" maps with this .utx package, it should not appear an error message?

Chamberly
12-17-2015, 04:55 PM
It is just better to make a different filename for it because if 1 person have a file mismatch with a .u vs .utx it's best to redo it anyway, many other ppl would have the same situation when you don't.