Lag and desync, why?

[Softegg 0]

i am searching for information about the reason of lags and desyncs.

there are some events that seems to produce a lot of data-traffic like dammaging a house or driving over a bush or tree. also, if 2 or 3 people are driving together in a vehicle, the traffic is high.

but something like a local running rotorwash-script for a chopper is also producing traffic/lag/desync?

is desync corresponding with high data-traffic (upstream and/or downstream)?

maybe a list would be good, sorted by traffic/lag/desync-tendency.

EDIT:

or maybe things like the number of objects on the island are essential?

maybe a simultan (sorry for my bad english) running voice-program like teamspeak is removing a lot of bandwith from the ofp-data-stream?

[Gadger 0]

I have no idea what your talking about, but it sounds good

[Certa 0]

Desync happens when one client lose track of what one or more other clients are up to. It is more likely to happen when there are many players, a lot of network traffic and a lot of packet loss of the network. It can also show up because of software bugs.

I wrote some related things in the OFP2 suggesions forum.

Client/Server model

[KeyCat 131]

I think there are lots of different things that can affect lag/desync...

 - Server bandwitdh and quality of connection

 - Client bandwitdh and quality of connection

 - Server performance (CPU and RAM)

 - Client performance (CPU and RAM)

 - Number of AI's in mission

 - Number of triggers in mission

 - Number of objects on map

- Number of players

 - Number of assigned WP's in mission

 - Number of server sided script used in mission

 - To much use of the PublicVariable command in script

 ...

I'm sure there are other factors as well, this is just from top of my head.

Quote[/b] ]

but something like a local running rotorwash-script for a chopper is also producing traffic/lag/desync?

We haven't experinced any lag issues with thinsg like a rotowash script running local on the clients if the client computer is capable to handle the added "burden" with acceptable framerate.

Quote[/b] ]

maybe a simultan (sorry for my bad english) running voice-program like teamspeak is removing a lot of bandwith from the ofp-data-stream?

Probably depends on what bandwidth you have available. We use TeamSpeak all the time and it works great! Most of our guys are connected via xDSL or better so things may be different if you are using a 56k modem.

When I do a mission/script we usually test play it several times before I add "to much stuff" and see how it performs (i.e ask the players if they notice lag etc). Also the "monitor" command on a dedicated server is a great tool to see if your mission is to much for your server.

/Christer (a.k.a KeyCat)

[blackdog~ 0]

It would be very nice if BIS added a CPU Usage (either in percent or megahertz) because I'm worried how much my server will use because it's running a webserver as well.

Something like this when you do #monitor would be cool..

CPU Usage: xxxxxMHZ/xxxxxMHZ

[Certa 0]

It would be very nice if BAS added a CPU Usage (either in percent or megahertz) because I'm worried how much my server will use because it's running a webserver as well.

You should have diagnistic tools for that already included in your OS.

On NT (2K/XP) you can use system monitor or any 3rd party tools of choice.

Not sure about Linux but I'd be surprised if you don't have any tools similar to the system monitor.

[kegetys 2]

It would be very nice if BAS added a CPU Usage (either in percent or megahertz) because I'm worried how much my server will use because it's running a webserver as well.

When theres a mission going on, the server of course uses everything the OS gives to it, unless its running at 50fps which seems to be the limit... If you need to ensure your webserver to get cpu cycles as it requires them, then priorize the web server process higher than the ofp server process.

[Chris Death 0]

Quote[/b] ]It would be very nice if BAS added a CPU Usage

It would be even more nice, if BIS would do that,

rather than BAS doing it.

btw - vehicles (expecially flying one) do cause a lot of

lag sometimes.

Objects stuck into other objects do cause heavy lag aswell.

And nearly unplayable lag was always caused by the so called

"ammo bug", where too much ammo was added to crates or

vehicles, just lying around the crate/vehicle.

~S~ CD

[blackdog~ 0]

Quote[/b] ]It would be very nice if BAS added a CPU Usage

It would be even more nice, if BIS would do that,

rather than BAS doing it.

btw - vehicles (expecially flying one) do cause a lot of

lag sometimes.

Objects stuck into other objects do cause heavy lag aswell.

And nearly unplayable lag was always caused by the so called

"ammo bug", where too much ammo was added to crates or

vehicles, just lying around the crate/vehicle.

~S~ CD

Indeed it would......

=/

[suchey 0]

use

#monitor 60

where 60 is the number of seconds between reports.

your servers FPS has a high of 50 (meaning the server isnt even using all of the resources available)

BIS suggested a low of around 15...15 and below being your server doesnt have enought resources to run that ammount of players using that ammount of resources.

FPS will vary from mission to mission depending on whats going in in regard to scripts, number of players on the server, etc etc.

My adive would be to stick with mission that run at fairly high FPS...if you find that FPS is low on all missions, its time to jack down the number of players you can allow on the server.

Air units seem to be the biggest hit in regard to desync. Especially aircraft which arent really something I would reccomend running on a server. Helecopter have some issues, but not nearly as bad. You may be able to get away with a few helecopters if you have a alot of bandwidth and decent server.

Desync can also spread from client to client. When one really bad connections beings to desync badly, other player who come into contact with that person are more likley to show signs of desync themselves. You will notcie that (if you can isolate the single bad connection...usually the one with the most consistant and highest desync) most times if the bad connection leaves, the rest will even back out. SOrry to say that most times desync comes from the client end (in relation to dedicated servers). Its best to find a server that is geographically close and stick with it unless your lucky enough to get really good connections on multiple servers.

[zinco 0]

Its the shilkas, vulcans, and the smoke, grenades. they will blast fps on the best of servers.

[Softegg 0]

if event-triggers and client-side-scripts are not also be called at the server, could this reduce the server-stress?

sample:

1. creating a logic-object named 'Server'.

2. init.sqs

...

IsServer=(local Server)

...

? ! IsServer: [chopper] addventhandler [...]

...

[Chris Death 0]

Softegg, i tell you what;

too much useless stuff causes loss of perormance and

further this will also infect network traffic.

e.g:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">1. creating a logic-object named 'Server'.

2. init.sqs

...

IsServer=(local Server)

...

? ! IsServer: [chopper] addventhandler [...]

...

IsServer=(local Server)

is a useless line

?!IsServer: [chopper] addeventhandler [...]

let's the game to have to think: what again was IsServer?

ah it's (local Server)

If you would just use:

?1(local Server): [chopper] addeventhandler [...]

you would get the same result with only one line and

no refer to the context of a variable.

~S~ CD

[Softegg 0]

i use this

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

IsServer=local Server

because its easier for me to memorize.

and also i think it's (minimally *G*) faster to set only one time the boolean variable 'IsServer' and further using it, than always calling the function 'local object' which (internally) needs to check and calculate a lot of things until giving me back the same 'TRUE' or 'FALSE' again and again.

[Chris Death 0]

Quote[/b] ]and also i think it's (minimally *G*) faster to set only one time the boolean variable 'IsServer' and further using it, than always calling the function 'local object' which (internally) needs to check and calculate a lot of things until giving me back the same 'TRUE' or 'FALSE' again and again.

And i still tell you that you're totally wrong with your thinking

here.

OFP doesn't just check, wether IsServer is true or not.

IsServer is just defined to represent:

(local Server)

Now this information needs to be saved somewhere

While (local Server) is either true or not

Now whenever you check wether IsServer exists or not,

the game needs to look there to know what IsServer

represents, followed by checking if (local Server) exists

or not.

Double work for one thing.

Now if you mean that this is not really important to think

about, than ok.

Just tried to show you, that using 2 times more than required

also causes 2 times more than expected.

Why then would you think that assembler was so much faster

than basic, or other interpreted programmer languages?

And btw - even if it just runs local as you think, the part of

the reference codes has still to be transferred through the

network, and in your case two times (not only once).

Also when you say: it's not such a big thing to think about

Most of the problems in every case do start small and easy,

and if you want to optimize something, than best you would

start by sorting out the smallest things first, as in summary

such small things can cause much more troubles than it may

look from the first view.

~S~ CD

[Softegg 0]

Quote[/b] ]

OFP doesn't just check, wether IsServer is true or not.

IsServer is just defined to represent:

(local Server)

Now this information needs to be saved somewhere

While (local Server) is either true or not

Now whenever you check wether IsServer exists or not,

the game needs to look there to know what IsServer

represents, followed by checking if (local Server) exists

or not.

i dont go conform with this.

what is 'IsServer'? 'IsServer' is primary a global undefined variable. by setting 'IsServer=TRUE' or 'IsServer=FALSE', the variable is declared as boolean variable, and only contains the value 'TRUE' or 'FALSE'.

what is 'local Server'? this is calling a internal ofp-function which needs to check and calculate some things to give back a result.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

'IsServer=local Server'

fills the global variable with 'TRUE' or 'FALSE'.

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

? IsServer : ...

don't looks back for the defintion or declaration and calls again the function 'local Server', it just checks if 'IsServer' is 'TRUE' or 'FALSE', because 'IsServer' is just a global boolean variable.

if you want to build something like you explained it, you must write and declare/call a function like this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

IsServer.sqf

_return = local Server;

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

IsServer=loadfile "IsServer.sqf"

...

? call IsServer : ...

[killswitch 19]

Yep, what softegg said. Don't confuse assignment of variables with definitions of macros or function calls.

[Softegg 0]

ok, now back to the main theme please !!!    

[Chris Death 0]

I must say: yeah you got me here

I didn't think about the fact that you're just capturing

the actual state of (local server) with the boolean IsServer.

I came to this misthinking because of working too much with those arrays and transferring one array into another one, etc.

Arrays do interact, so if you say: array1 = array2, then array1

would be updated, in case array2 has changed.

In case of IsServer you're right.

But what's still using more performance is the one line too

much. Not saying that just not leave as the looser here  

but if you think about memory allocation, and performance

usage because of 2 lines instead of one, i'm still right.

May it be serverside or clientside.

In case of only one more line, it may really not matter, but

when it comes to many double-liners, it may affect low end

clients ==> other clients (chain reaction effect) aswell.

Still nothing to worry about in the IsServer case, but true.

One thing to correct: IsServer is a local boolean, not a global

one in your case.  

OK, now back to the main topic:

A whole lot of manually added objects like sandbags,

houses do cause lag or desync upon slowering down the

clients.

Also triggers with a large size do cause lag (mentioned

by SUMA some time ago).

A big number of units/groups starting to move at the very

same time do it aswell.

e.g: 20 groups waiting at their first waypoint, just to become

triggered by the same trigger to have a go for their destination.

Unnecessary loops with a short delay do eat more performance

than such ones with a longer one.

Some ppl do not think about, how often they really need to check something.

For example: checking wether all units of a group got killed

yet is not really important to do every 0.05th second, etc.

~S~ CD

[killswitch 19]

Lots of good points there, Chris! I too cringe when I see loops such as (somewhat exagerrated)<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

#loop

?!(alive somedude): goto "next"

~0.000001

goto "loop"

...

...

...

#next

....

with very short loop delays. If this is a script that runs in many instances on a server they will hog the CPU like it's going out of style (the "lets wait for 1 microsecond" is the culprit).

Other sources of lag/desync: doing too much almost at the same time. A classic example of this is spawning a group of units and running a CPU-intensive "init script" for each of them. As an example, here's an excerpt from D.Murphy Mans older version of the Skye Virus. That mission lagged horribly every time a new group of zombies was spawned. This is the code where three of the seven zombies gets spawned:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

"civilian" createunit [getpos _trig,bob,"zombiename1=this;[zombiename1,man1] exec {zombie.sqs};zombiename1 addweapon {strokefist};this setbehaviour {careless};this setunitpos {up};this setdammage 0.80;group=grpNull"]

~1

"civilian2" createunit [getpos _trig,bob,"zombiename2=this;[zombiename2,man1] exec {zombie.sqs};zombiename2 addweapon {strokefist};this setbehaviour {careless};this setunitpos {up};this setdammage 0.80;group=grpNull"]

~1

"civilian3" createunit [getpos _trig,bob,"zombiename3=this;[zombiename3,man1] exec {zombie.sqs};zombiename3 addweapon {strokefist};this setbehaviour {careless};this setunitpos {up};this setdammage 0.80;group=grpNull"]

~1

...

// four more zombies in a similar way

...

Have a look at the "init code" part of each createUnit call - there's a script (zombie.sqs) started followed by some unit setup commands. Zombie.sqs, on start, immediately enters a "~1 delay loop" to chase the player.

The code above doesn't look like too much for our 1+ GHz computers of today, but still, I was able to do a few things to it. What I did was to strip the createUnit init string down as much as possible and move all of the unit setup things (weapons, behaviour and such) into a slightly changed zombie.sqs. Here's the first createUnit line from the new spawn script:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

// Spawn the zombie if it doesn't exist and only on the server

? isNull zombiename1 and local Server:"civilian" createunit [getpos _trig,bob,"zombiename1=this;[zombiename1,man1] exec {zombie.sqs}"];

And the relevant part of a new variant of the zombie control script:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

...

; Wait a while before "activate" the zombie. This to lighten the load while spawning a lot of

; zombies, since each one executes this script on creation.

~(5 + random 5)

// Stuff moved from the createUnit init parameter

[_zombie] join grpNull;

_zombie addweapon {strokefist};

_zombie setbehaviour {careless};

_zombie setunitpos {up};

_zombie setdammage 0.80;

...

...

// zombie starts looking for fresh player brains...

I guess what I'm trying to say is: when one spawns many units in a short time, don't run a lot of CPU-intensive code at once. A good trick is to move a lot of the init code into a script and let that script sleep a random amount of time when it is run. That way one can spread the CPU load over time a bit, thereby lessening the "cpu lag".

The catch: with this cpu-lag reducing technique, don't go overboard on your spawning needs. The desync, I believe, would increase since a lot of new entities are created on e.g. the server and needs to be replicated on all player clients.

So:<ul>[*]Like DV Chris said, dont do ~0.0000000001 loops

[*]Dont spawn units without spreading the load over time